08 sept. 2010

Alors, qu'est-ce qu'un architecte ?

Il y a peu de temps, j'ai publié un article qui expliquait les différences entre l'architecture logicielle et la conception logicielle. Au fur et à mesure de mes pérégrinations "internetienne", je lis des chose, et je m'aperçois que les définitions que j'ai donné dans cet article, bien que relativement juste, n'en sont pas moins terriblement incomplètes. En cause, la définition même de mon métier : quel est le travail de l'architecte logiciel ?

Je vais être honnête avec vous : à ce stade, je n'ai pas vraiment de réponse à cette question. J'ai des éléments de réponse, oui - j'en ai déjà livré quelques uns sur ce blog. Mais pas de réponse complète, définitive et correcte.

Je vais donc vous poser une série de questions :

  • Qu'est-ce que l'architecture logicielle ?
  • Qu'est-ce qu'un architecte logiciel ?
  • Quel est le travail d'un architecte logiciel ?
  • En quoi ce titre est-il adapté ?

J'attends vos réponses avec une impatience non dissimulée !

Commentaires

1. Le mercredi, septembre 8 2010, 18:38 par Victor Nicollet

L'architecture logicielle est à mon humble et partial avis une forme très répandue de masturbation professionnelle. Il faut bien entendu avoir un minimum d'architecture dans tout project, en ce qui concerne les grands axes et les grandes directions sur lesquelles il sera très difficile de revenir par la suite; toutes les choses pervasives (celles qui affectent toutes les parties du projet : frameworks, plates-formes, langages de programmation, structure des bases de données) doivent faire l'objet d'une décision mûrement réfléchie pour éviter qu'elles n'entrent en contradiction avec des objectifs exprimés ou prévisibles. Mais nous savons tous les deux qu'avoir trop de choses pervasives dans une application rime avec désastre. Et les choses qui ne sont pas pervasives coûtent si peu cher à changer (avec une équipe de développement de qualité) que cela n'en mérite pas l'effort de les prévoir trop en avance.

Le travail d'un architecte est donc de se renseigner sur les stratégies d'architecture utilisées par ailleurs, de les mélanger et les tester sur des petits prototypes pour voir les limites les plus évidentes de chaque approche, et de faire une préconisation en français (ou anglais, souvent) pour que les développeurs puissent ensuite remplir la trame qu'il a tracée (un peu comme les abeilles versent le miel dans les alvéoles déjà présentes).

Trop souvent, j'ai vu des postes d'architecte servir d'excuse à un expert qui impose des limites rigides pour empêcher des développeurs pas toujours brillants de faire trop de bêtises (ou en tout cas, des bêtises trop difficiles à inverser). Mais il ne faut jamais sous-estimer la créativité des développeurs : une architecture doit être une proposition "c'est ainsi qu'on fait les choses le plus simplement" plutôt qu'une restriction "c'est comme ça qu'on fait et pas autrement". Deux façons de regarder la même chose (une direction donnée au projet) mais l'une est plus motivante que l'autre.

Trop souvent, j'ai vu un architecte décider que le problème est un cas particulier d'un cas particulier d'un cas particulier d'un problème très général. Et ce qui devait être un ensemble de deux formulaires et trois tables devient une usine à gaz de vingt formulaires, cinquante fichiers de configuration et trente tables, qui peine à résoudre le problème original. Car pour être architecte, il faut être du côté obscur de la force avoir une bonne aptitude à l'abstraction, et quand on a cette aptitude, on est possédé d'une volonté irrépressible de s'en servir à tout va.

Qui n'a jamais pensé que retirer le premier caractère d'une chaînes de caractères n'était qu'un cas particulier de la fonction substring? Alors que retirer le seul premier caractère arrive plus fréquemment que n'importe quelle autre extraction de sous-chaîne!

2. Le vendredi, septembre 10 2010, 14:10 par Emmanuel Deloget

Ah la la la la :) Je crois que mon métier souffre d'un déficit d'image :)

Ceci dit, tu n'as pas tort : trop souvent, l'architecte prescrit des solutions qui d'une part ne sont pas forcément adaptées et d'autre part ne sont pas explicitées - ce qui conduit à des clash systématiques avec les équipes de développement.

J'essaie de trouver une réponse par moi même, et le moins que je puisse dire, c'est que c'est assez particulier. D'une part, on a une norme qui est censée définir ce qu'est l'architecture logicielle (IEEE 1471, acceptée par ISO comme un standard international). D'autre part, on a la définition de ce qu'est, à l'origine, un architecte (telle que donnée dans De Architectura il y a environ 2030 de nos pitoyables années). Il faut que j'arrive à réconcilier tout ça, et ça me donnera probablement suffisamment de matière pour écrire un livre :)

3. Le jeudi, septembre 16 2010, 15:52 par Brice

Salut Emmanuel,

C'est une bonne question et assez innatendue, cette question s'applique aux autres métiers. Typiquement, pour rester dans le monde du logiciel, quelles sont les responsabilités d'un développeur, qu'est-ce qu'il a à faire pour justifier ce "poste" ? Dans certains projets, un développeur pourra toucher à la prod, à l'intégration web, à la base de données, il sortira de son rôle de développeur pour accomplir certaines tâches avec plus ou moins de recul.

Donc avant de répondre à ton interro, je voulais dire que le périmètre d'un "poste" n'est pas borné, on peut faire moins comme plus. Bien évidement sans aller dans les extrêmes pour avoir X casquettes différentes ou n'avoir rien à faire dans son boulôt d'architecture.

Aussi je suis à 90% d'accord avec Victor, aujourd'hui un architecte c'est quelqu'un qui est bon, ou au moins qui pense l'être, et qui aura un recul suffisant pour comprendre qu'il n'y a pas que le code dans un projet. Et donc dans la plupart des cas aujourd'hui c'est de la branlette intellectuelle, je suis assez cru, mais je ne peux pas penser autrement.

L'explication est simple : en France on ne reconnait pas très bien le boulôt technique, à la fois socialement et pécunièrement. Donc ceux qui veulent rester technique et avoir un peu plus d'argent par rapport à leur expérience (pour s'acheter une maison) ont deux choix : soit ils restent developpeur, soit ils deviennent chef de projet ou analyste métier, ou encore autre chose.
Mais notre Mère Nature a doté ses petits de la faculté d'adaptation, donc pour contourner le problème, on se dit que plutôt que de faire un autre métier, il est possible de faire reconnaitre sa valeur en étant architecte. Bien entendu la complicité des différentes parties aide à installer cette semi-imposture.

Mis à part ce petit détour, voici mes réponses à tes questions:

Qu'est-ce que l'architecture logicielle ?
L'architecture logicielle, c'est l'organisation des briques d'un logiciel en une structure cohérente qui assure au logiciel d'être en mesure de remplir les objectifs et de respecter les propriétés attendus.

Les objectifs du logiciel pouvant donc varier, je citerais par exemple

  • qu'on attends peut-être du code jettable,
  • peut-être qu'à l'inverse on attends que le logiciel soit facilement maintenable et évolutif,
  • on peut aussi demander qu'il soit résilent à certaines pannes,
  • qu'il soit scalable,
  • qu'il ait une capacité de traitement constante,
  • que le logiciel puissent s'interfacer sur certains éléments du SI,
  • que la sécurité du logiciel respecte un certain standard,
  • que logiciel soit structurer de telle façon pour respecter des contraintes légales,
  • qu'il puisse être en mesure de respecter un SLA,
  • etc.

En tous cas dans un SI, l'architecture logicielle reste très périphérique à une application. Dès qu'on sort pour regarder sur les applications qui composent un SI responsabilités ont une granularité moins fine, on parle alors d'urbanisation du SI.

Bien entendu l'architecture n'est pas figée, il s'agit davantage d'une vision réfléchie de la structure logicielle qui évolurait parralèlement au cycle de vie du logiciel.

Qu'est-ce qu'un architecte logiciel ? Quel est le travail d'un architecte logiciel ?
C'est la personne qui sera capable de poser à la fois les questions techniques, métier, légales, pour comprendre les enjeux de l'application. Être architecte ce n'est pas simplement dessiner des boites pour faire sa conception et réaliser un prototype fonctionnel.
Au delà d'un concepteur de haut-niveau ; l'architecte, c'est l'homme qui va définir la structure du logiciel qui va respecter les contraintes et les propriétés variés tout garantissant que le logiciel accomplira l'objectif attendu.

C'est également l'homme qui aura la vision du logiciel, et qui devra la communquer à son équipe et autres entités impliquées (qui ne sont pas liées au développement) si nécéssaire. Bien entendu la communication devra cibler l'audience. Si l'équipe a besoin d'aide ou si elle a des propositions, c'est aussi à l'architecte d'entretenir le dialogue. Sans feedback, il y a peut de chance que quelqu'un puisse s'améliorer.

En quoi ce titre est-il adapté ?
Aujourd'hui en effet on peut se poser la question du titre et du poste d'un architecte: est-ce adapté, est-ce du zêle, est-ce de la branlette intellectuelle? Avant-hier justement, on m'a dit que dans la plupart des projets un architecte ça ne sert à rien, en Java en particulier pourquoi y-t-il besoin d'autant d'architecte?

En fait la réalité d'un projet fait qu'on a besoin de quelqu'un qui va endosser ce rôle pour répondre a ses responsabilités. Dans un projet assez petit, avec 3 personnes par exemple, je doute de la réelle utilité, ceci dit celà ne veut pas dire qu'il n'y a pas d'architecture, et il faudra toujours cependant un interlocuteur privilégié, mais il n'aura pas nécéssairement ce rôle d'architecte reservé à une seule personne. Sur un projet plus gros, qui demande de la réflection, de considérer des choses qui sont en dehors du développement propre, un rôle d'architecte peut sembler approprié.

Et vis-à-vis des architectures rigides, ou encore des architectures super-génériques à outrance, etc. L'idée c'est quand même d'avoir du bon sens. Dans les méthodlogie agile on dit "Plan your work, work your plan", c'est bien de prévoir, mais les chose change et il faut savoir changer les chose en cours de route. L'architecte doit en être capable aussi!
Egalement aussi le feedback, un architecte doit avoir du feedback et il doit le prendre en compte. Dans un article que j'ai écris sur le pair-programming je dis que c'est plutôt pas mal d'être challengé par par son équipe ou par un autre architecte, d'ailleurs je parle même de pair-architecturing.

Voilà, c'est mon avi sur le sujet. En tous cas j'aurais appris que l'architecture logicielle est normalisée par ISO.
A titre d'information la maintenance logicielle est aussi normalisée (ISO/IEC 14764).
En parlant de norme je me rappelle qu'il y la norme ITIL qui couvre pas mal de secteurs du logiciel dans un SI. Aussi intéréssant à connaitre c'est la méthode Praxeme qui véritablement une méthode d'architecture logicielle. Bref à connaître.

4. Le lundi, septembre 20 2010, 15:08 par moustov

architecte : en grec "αρχιτεκτων" (arkitekton), littéralement "la poutre maîtresse", "l'ossature principale".

à mon sens, c'est bien plus lié à fournir une vision structurale que les dev devront mettre en chair que de faire des diagrammes de classe à tours de bras.

on l'aura compris, une architecture doit être partagée et cette appropriation des devs est indispensable pour être implémentée correctement. du coup, j'ai l'intuition (en fait "généralisation de ce que j'ai constaté dans différentes boites") que son rôle est de proposer des gros cailloux qui sont cohérents entre-eux et qui parlent à tout le monde pour que les équipes de réalisation (ceux qui chosifient l'ossature) prolongent la vision de façon tout aussi cohérente.
d'après tout ceci, l'architecte serait donc le garde-fou de cette vision et celui qui a une vision transverse sur le produit.

un autre rôle de l'architecte qui peut être rencontré est le garant technique, celui qui sait où/comment taper pour résoudre un problème/trouver une solution technique dans les règles de l'art disponibles dans les process area "Casual Analysis & Resolution" et "Technical Solution" du CMMi.

ensuite, suivant les métiers, l'architecte a une obligation morale voire réglementaire de traçabilité entre les specs & l'architecture (voir "Requirement Developement" du CMMi).

tous ces éléments purement théoriques doivent être teintés de la particularité de ce rôle transverse au sein de(s) l'équipe(s) ; en effet, sa position fait qu'il est rarement le responsable des développeurs et que sa vision ne peut pas être imposé. cette casquette de "manageur transverse" rend le poste très délicat où l'architecte est coincé entre le normalisateur-qui-fait-ch*** et celui-qui-veut-aider-à-trouver-des-solutions-alors-qu'une-évidence-saute-aux-yeux...car en plus de ça, bien des dévs pensent pouvoir être architecte à la place de l'archi.

dans ce positionnement où l'iznogoud est enfin devenu calife à la place du calife, l'archi est avant-tout quelqu'un qui a la tête dans les nuages et les pieds sur terre ; il sait se faire entendre et a la sagesse d'écouter, tout comme tu le fais mon cher Manu, en donnant la parole à d'autres architectes.

5. Le mardi, septembre 21 2010, 15:09 par Brice

L'architecte est avant-tout quelqu'un qui a la tête dans les nuages et les pieds sur terre

Cette métaphore me plait !

6. Le mardi, septembre 21 2010, 23:14 par Emmanuel Deloget

Et bien, que de commentaires intéressants !

De mon coté, je poursuis mes recherches, et je vous livre un article supplémentaire très bientôt !

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet