Qu’est-ce qu’un architecte Solution ? Quel est son rôle ?
L’architecte Solution accomplit son rôle dès la phase de conception de l’architecture du système d’information, il conçoit les différentes briques du SI.
Il a aussi pour responsabilité leur cohérence ainsi que leur évolution dans le temps. L’architecte accompagne les différentes phases d’un projet jusqu’à la mise en production et au-delà dans le cadre du cycle de vie de l’infrastructure pour les évolutions technologiques et les nouveaux besoins.
L’architecte peut aussi, selon les contextes, accomplir des missions à caractère ponctuel comme du conseil ou de l’audit. C’est-à-dire intervenir dans des projets ou des environnements dans un but précis, qu’il soit lié à une expertise ou à une approche méthodologique.
L’architecte Solution est au système d’information de l’entreprise ce que l’architecte est à son projet BTP.
Quelles sont ses tâches ? Avec qui travaille-t-il ? Quelles sont ses compétences ?
Pour mener à bien sa mission, ce qui doit retenir l’attention de l’architecte dans un premier temps sont les besoins du client qu’il soit interne ou externe.
Il s’appuie sur la cartographie du SI et le modèle d’architecture d’entreprise pour proposer et mettre en œuvre une infrastructure matérielle et/ou logicielle pertinente.
L’architecte Solution travaille généralement en équipe, en relation avec les experts des différentes disciplines (système, stockage, réseau), et en interface avec les différents métiers de l’entreprise.
L’architecte Solution doit maîtriser l’organisation de l’entreprise et son infrastructure technique afin de toujours privilégier des solutions simples robustes et facilement exploitable.
Tout au long de sa carrière l’architecte gagnera à étoffer non seulement ses compétences techniques mais aussi ses compétences intra-personnelles qui lui permettront de faire la différence dans nombreuses situations qu’implique son rôle, il doit également posséder de bonnes capacités relationnelles et stratégiques, ainsi qu’un goût pour la négociation, dans la mesure où il sera amené à interagir avec une grande diversité d’acteurs aux objectifs différents.
Mais alors qu’est qu’un architecte junior ?
Maintenant que nous avons défini le profil de l’architecte Solution et son large périmètre d’intervention, définissons ce qu’est un architecte solution junior.
C’est un débat sans fin qui divise ! Qu’est ce qui définit un architecte ? Son expérience et son expertise ou sa méthode et sa posture ?
Certains vous dirons son expertise, d’autres sa méthode, et les plus clairvoyants (ou occupés !) vous diront de manière plus ou moins concise les deux !
Force est de constater que deux visions s’opposent.
La première définit le rôle d’architecte par l’expérience et l’expertise acquises dans un domaine donné (Architecture métier, fonctionnelle, applicative, ou encore technique).
Lorsque l’on regarde l’architecte avec pour seul paramètre son expertise technique, l’architecte junior n’a alors pas beaucoup de sens. Car l’expertise technique se mesure aujourd’hui par un nombre d’années passées au contact d’une méthode ou d’une technologie ainsi que des compétences brutes.
La confusion persiste cependant pour la raison suivante : l’architecte a été utilisé comme « statut » pour valoriser l’expérience d’un expert technique. Il était ingénieur puis au bout d’un certain nombre d’années d’expérience, se voyait couronner de ce statut d’architecte, tant bien même qu’il exerçait un métier d’ingénieur.
Cette tendance n’est pas mauvaise en soi, mais à l’heure où les usages et les rôles évoluent à une telle vitesse, ces confusions peuvent vite devenir pérennes.
L’autre posture consiste à définir l’architecte par son rôle au sein d’un projet donné ainsi que par les « lunettes » avec lesquelles il regarde un système. L’architecte junior prend alors tout son sens.
Ces « lunettes » sont en réalité une méthode et plus un architecte est expérimenté (et a de l’expertise), plus il est susceptible d’être habile dans l’utilisation qu’il fait de cette méthode dans la conduite de ses tâches et de ses échanges selon les contextes.
Une fois cela dit, apprendre à un jeune architecte à tenir son rôle et calibrer les lunettes avec lesquelles il regarde les systèmes est donc requis et s’apprend !
Pour ce faire, faire évoluer un profil junior au milieu d’architectes plus expérimentés est une manière d’outiller, de rendre autonome et efficace une architecte dit « junior ». A condition qu’il parvienne à dépasser le fréquent syndrome de l’imposteur des débuts 😊
Pour clôturer le débat, ces deux visions se valent et se complètent dans la mesure où c’est le contact et la collaboration des profils expérimentés et de ceux en quête d’expérience dans la réalité des organisations d’aujourd’hui qui valide la seconde vision.
Lunettes, méthode, qu’en est-il ? Comment un architecte regarde (ou doit regarder) un système ?
Dans cette partie nous allons nous concentrer sur le cœur du rôle de l’architecte, il s’agit de la matérialisation de sa méthode en un livrable au sein d’une organisation.
Cette méthode à laquelle j’adhère, je l’ai hérité des architectes plus expérimentés avec lesquels j’ai eu la chance d’évoluer. Elle se veut efficace et concrète mais pas forcément exhaustive ni spécifique.
S’il l’on devait associer un et un seul livrable à l’architecte, c’est le document d’architecture technique (DAT), ce document vit et évolue avec le système ou l’application qu’il décrit. La méthode que je décris ci-dessous peut être vue sous 2 angles :
- Une vue macro des différentes couches qui se superposent et qui constituent la documentation nécessaire à un système ou une application.
- Un plan concret pour rédiger un document d’architecture technique.
4 couches pour décrire un système, une application :
La couche fonctionnelle
On y décrit les éléments suivants :
- Les utilisateurs d’un système
- Les données que gère et/ou transitent par ce système
- Les traitements réalisés par ce système
- Les interfaces avec les autres applications
La couche applicative
On y décrit les éléments suivants :
- Les flux techniques correspondants aux transits de données et aux traitements réalisés par le système (protocoles, port, sens du flux)
- Les modules applicatifs
- Les Middelwares (serveurs d’applications, bases de données, plateformes d’échanges, services en tout genre)
La couche technique ou la couche infrastructure
On y décrit :
- Les puissances de calcul (Serveurs, VMs, conteneurs)
- Le réseau (Interconnexions, débits, liens, latences…)
- Le Stockage (format, disques, accès, performances)
La couche opérationnelle
On y décrit :
- Le monitoring (disponibilité, performances, supervision spécifiques…)
- Le métrologie (Collecte, fréquence et rétention des logs système et applicatifs)
- La politique de sauvegarde
- Les processus (ordonnancement), traitements récurrents (batchs) ou occasionnels (rafraichissement d’environnements, mises à jour)
Ces 4 couches couvrent les silos traditionnels des entreprises (Design, Build, Run) tout en se rassemblant dans un seul et même document. Il évoluera pendant tout le cycle de vie du projet pour intégrer les évolutions technologiques et les nouveaux besoins.
A chaque couche correspond un objectif, à chaque couche correspond un type de schéma avec sa nomenclature lorsque ces derniers ont pour but d’être partagés aux différentes parties prenantes.
En conclusion
Dans une perspective absolue, au sein du système d’information, l’architecte Solution est le pont entre le besoin du client et la production, il est le dépositaire de la méthode et le garant des solutions techniques, il a pour rôle l’élaboration et le maintien des standards dans le temps.
L’architecte doit chercher à perfectionner sa méthode et son expertise en parallèle, et les différentes expériences enrichiront ces deux dimensions constitutives de son rôle. Les capacités d’auto-formation et de renouvellement sont tout aussi importantes.
L’enjeu pour un architecte junior est donc d’adopter une attitude disciplinée mais critique, disciplinée dans l’application d’une méthode et dans l’acquisition de compétences et d’expertise. Et une attitude critique pour se développer et se renouveler au fil de sa carrière et ainsi cultiver sa valeur ajoutée propre.
A titre personnel, j’ai pu utiliser cette méthode dans de nombreux contextes et environnements différents. Elle facilite les échanges dans le déroulement d’un projet pour plusieurs raisons et elle permet de compartimenter les domaines d’expertises.
Enfin, elle amplifie la dimension de catalyseur inhérente au rôle de l’architecte, car bien conduite elle permet de laisser un document d’architecture lisible, accessible et facile à faire évoluer dans le temps.
Sources :
https://www.metanext.com/methode-darchitecture-metanext-openclassrooms/
par Mehdi TAOUINET, Architecte Solutions Junior
