l y a quelques temps, j’ai été amené à donner ma définition du rôle d’un architecte logiciel dans une petite équipe et indiquer quelles sont à mon sens les qualités requises pour remplir cette fonction. Cet article reprend la réponse que j’avais alors fournie. J'espère qu'elle vous permettra de mieux comprendre le rôle et les devoirs d'un architecte.

Architecte ou ArchitecteS ?

Le terme "architecte logiciel" est assez vague. La définition que l’on peut en donner dépend du contexte. Je m’intéresse ici à un architecte intervenant dans une équipe petite à moyenne, sur plusieurs projets mais de nombre relativement restreints. Dans ces conditions, l’architecte logiciel joue aussi le rôle d’expert technique sur une ou plusieurs plates-formes.

Lors du symposium DotNetGuru 2003, Sami Jaber a présenté deux types d’architectes :

• les architectes fonctionnels, qui optimisent les processus métier, et ont une très bonne connaissance des méthodes d’analyse ;
• les architectes techniques, qui conçoivent des architectures techniques pérennes, robustes et évolutives, et qui sont le pont entre le chef de projet et les développeurs.

On peut également rencontrer d’autres types d’architectes. Vous pourrez vous référer aux ressources présentées à la fin de cet article pour en savoir plus. Nous nous intéresserons ici aux architectes techniques, et non aux architectes fonctionnels.

Reprenons le rôle d’un architecte technique tel que présenté par Sami :

• Anticiper les évolutions technologiques
• Bâtir des architectures pérennes
  • Indépendance vis-à-vis d’un fournisseur d’API/Framework
• Mettre en place un minimum de généricité et d’abstraction
• Un pont entre les développeurs, chef de projet et experts métier
• Rôle d’évangélisation technologique, sens aigu de la communication
• Garant du schéma directeur technique et des choix adoptés
• Une culture souvent mixte (.NET/J2EE/Libre)
• Avant tout un rôle et non un métier

Tâches et compétences requises

Je ne donnerai pas ici une définition du mot architecte au sens ou je l'emploie. Je présenterai plutôt un certain nombre d’aspects du rôle d’un architecte logiciel technique, ainsi que les qualités requises pour remplir une telle fonction. Comme précisé précédemment, je m'intéresse ici essentiellement à un contexte de PME ou de service de développement de taille restreinte. Par conséquent, le rôle s'apparente souvent à celui d'expert technique.

On pourrait synthétiser les fonctions d’un architecte en quelques mots. Cela peut comprendre : effectuer des travaux de proposition, de préconisation, de conception, de réalisation, de validation, d’exposés, de comptes-rendus, d'encadrement, retransmettre sous la forme d’un message clair les technologies identifiées par une veille continue, être garant de la qualité technique des développements, …
Mais cela va bien plus loin. Le travail effectué par un architecte n'est satisfaisant que si celui-ci a compris que sa mission va au-delà de la simple expertise et de l’application des connaissances.

Un architecte est souvent un ex-développeur qui a acquis au fil des années une certaine expérience lui permettant d'asseoir son expertise. Cette expérience doit couvrir dans l'idéal une variété de plates-formes et de produits, et une connaissance de la vie d'une application, voire d'un système d'information.

Le rôle d’un architecte est unique par rapport aux métiers de développeurs ou même de chefs de projets par exemple, dans le sens où il demande un engagement sur le long terme, transverse aux projets et aux équipes. Cela est d’autant plus vrai quand il s'agit d'une collaboration de longue durée, plutôt que d'une mission classique de conseil.
Il s’agit d’un rôle clef au sein d’une équipe. L’architecte doit travailler main dans la main avec l’ensemble des membres de l’équipe et fédérer les énergies dont l’équipe fait preuve pour en retirer la meilleure essence.

Il est évident que l’apport d’un architecte tient beaucoup à son implication et son intégration avec les équipes projet. C’est par le biais d’échanges permanents avec les développeurs et les chefs de projet que l’architecte pourra communiquer ses connaissances, mais aussi surtout tirer le meilleur du travail de l’équipe et des individualités. L’architecte doit également être à l’écoute des besoins. Tout cela fait qu’il y a une forte composante relationnelle dans cette fonction qui requiert des capacités de dialogue.
Des qualités de pédagogue sont aussi requises pour pourvoir expliquer ses architectures, les discuter et les faire adopter.

Un architecte doit être capable de prendre du recul, ce qui est souvent difficile pour les développeurs et les chefs de projet qui sont souvent trop concentrés sur un projet donné et donc un besoin immédiat. Cela signifie avoir du recul par rapport à l'application pour remonter au niveau du système d'information de l'entreprise. Cela signifie également qu'il assure une veille technologique constante.

L’architecte doit soumettre des propositions pour l’orientation des développements avec une vision sur le long terme de l’architecture du système d'information et des problématiques d’intégration des applications, mais tout en gardant bien en tête les priorités. Il est par conséquent préférable de privilégier une approche pragmatique, par opposition à une ligne idéale qui doit rester un guide sur la durée et non un frein pour des développements qui sont très souvent contraints en terme de délais.
Mais autant un architecte doit savoir prendre du recul sur son travail et le travail des équipes, autant je conçois difficilement un architecte qui serait éloigné du terrain (le code, le projet). En effet, il peut être amené a écrire des lignes de code (ne serait-ce que pour créer des prototypes ou des maquettes), mais également à mettre les mains dans le cambouis pour valider la qualité de ce qui est produit ou décoincer une situation techniquement difficile. Il faut souvent quitter les beaux diagrammes UML ou les dossiers d'architecture pour regarder sous le capot comment fonctionne (ou ne fonctionne pas) l'application. Cela signifie donc surtout qu'il doit être capable de lire et analyser du code de manière très rapide.

Un architecte n'intervient pas uniquement en début de projet, mais tout le long du projet pour assurer la mise en application de la conception et de l’architecture. Il se doit également d’être constamment à l’écoute des besoins et des contraintes pour adapter les solutions si besoin. L'intervention d'un architecte peut par conséquent s’étendre à la durée de vie d’une application pour indiquer les nouvelles directions, et assurer que les évolutions ne fragilisent pas la construction.

Souvent un architecte sera à l'initiative de la création d’un framework maison, ce qui représente une part non négligeable de la capitalisation technique au sein d'une entreprise. Il deviendra alors responsable des orientations du framework et travaillera à ses évolutions futures.
Un framework permet également de faciliter l’adoption d’une plate-forme technologique telle que .NET ou J2EE. Autre tâche qu'un architecte peut assumer s'il est expert technique dans un environnement donné.

Pour reprendre ce que dit Sami, architecte est plus un rôle qu'un métier. Il ne suffit pas d'avoir de l'expérience, cela requiert aussi des qualités et avant tout un certain état d'esprit.

Architecte ou développeur ?

Pour terminer sur un ton plus léger, une question qui se pose souvent est comment distinguer un architecte logiciel d’un développeur ? Michael Platt écrit : "Les architectes mettent beaucoup plus de temps à trouver une solution, d’autant plus si le problème est simple !". Probablement que l’on pourrait ajouter que "les architectes sont plus à même de fournir des solutions complexes et coûteuses, d’autant plus si le problème est simple !".

Post-scriptum

Je profite innocemment de l’occasion pour rappeler que vous pouvez me contacter si vous souhaitez que j’intervienne dans votre société en tant qu’architecte logiciel ou expert technique…

Qui est Fabrice Marguerie ?
Fabrice Marguerie est architecte .NET chez Masterline. Fabrice intervient sur des missions de conseil, de conception ou de réalisation. Il a conçu et réalisé le framework .NET de Masterline.
Fabrice rédige un weblog en anglais : http://weblogs.asp.net/fmarguerie et gère le site http://SharpToolbox.com

Sa société : Masterline
Créée en 1989, Masterline est une SSII qui développe son expertise autour de trois marchés : business intelligence, e-business, SAP. L'accompagnement de Masterline prend la forme de prestations de conseil en technologies, d'ingénierie et services et d'externalisation, conçues et conduites avec pour objectif premier la création de valeur pour le client. Masterline développe ses expertises (.NET, Java, objet et UML, etc.) au sein de centres de compétences dédiés. Masterline est partenaire Microsoft depuis 1994.