Solution Architect : Mais quel est son rôle exactement ?

Que signifie ce rôle de Solution Architect ?

Comme beaucoup de rôle, il va dépendre un peu de l’entreprise où on l’exerce. Je vais donc expliquer ce rôle que j’occupe chez Padok depuis plus de 6 mois désormais. 

Pour rappel, Padok est une société de service spécialisée dans les infrastructures Cloud & On-premises, et possède 3 offres principales : 

• l’implémentation ou l’audit d’infrastructure,
• l’infogérance d’infrastructures Cloud (24/7 inclus)
• la sécurisation d’infrastructure à la suite d’audit de sécurité (pentests inclus)

Ainsi, en tant que Solution Architect, j’accompagne au quotidien les différents commerciaux de Padok lorsqu’il y a un nouveau prospect. Ma tâche est triple, et consiste à :

• Comprendre la stack technique du potentiel client ainsi que ses problèmes liés à l’infrastructure ;
• Définir la stratégie technique répondant à ses enjeux (architecture cible, choix de solutions) ;
• Estimer cet accompagnement afin de lui faire une proposition financière avec le commercial.

À chaque fois, un call technique de 30-45 min est organisé avec ce nouveau prospect dans le but de récupérer un maximum d’informations, pour que je puisse ensuite préparer la stratégie technique. Enfin, une soutenance d’une heure est organisée pour lui expliquer notre approche et les choix techniques proposés pour répondre à ses problématiques.

Exemple : je souhaite migrer mon infrastructure On-premises vers un cloud provider.

Quelles compétences faut-il avoir ?

Comme vous l’aurez compris, cela requiert d’avoir une bonne connaissance tech, et surtout qui doit être assez large. En effet, les contextes et usecases des clients sont très variés, ainsi que leur taille et leur niveau de maturité. Ainsi, on rencontre des stacks techniques hétéroclites, que ça soit au niveau des composants de l’infrastructure que pour l’architecture applicative et data.

Ensuite, il faut pouvoir comprendre les enjeux business du client, et identifier les chantiers les plus prioritaires à adresser. Il ne faut pas oublier que nos solutions techniques découlent directement de ces besoins, comme le time to market ou encore l’expérience utilisateur pour une plateforme e-commerce par exemple.

En outre, il est important d’avoir un bon relationnel avec différents types de personnes, et pouvoir adapter son discours pour chacune d’entre elles. Ainsi, il faut pouvoir ajuster son discours en fonction de son interlocuteur, et savoir expliquer clairement et simplement des choix techniques à un profil qui ne l’est pas, ou creuser des sujets plus poussés techniquement avec un profil expérimenté.

Pour finir, il faut avoir envie d’aider les gens, quitte à résoudre certains problèmes techniques avant même de travailler ensemble. C’est ce qui permet de créer une vraie relation humaine, et de se dépasser constamment.

D’ailleurs, je vous conseille de lire le livre “Getting Naked” de Patrick M. Lencioni qui illustre brillamment cette volonté d’aider, qui reste plus importante que vendre à tout prix.

Comment devenir Solution Architect ?

Pour identifier les axes de progression et définir correctement un plan de formation, une fiche de poste a été définie en interne avec des gestes associés. Voici quelques exemples de choses à maîtriser, mais il en existe bien d’autres :

• Connaître nos références clients et pouvoir en parler
• Mener un call technique pour récupérer toutes les informations nécessaires
• S’adapter à l’audience
• Faire une estimation
• Faire une stratégie technique pour migrer vers un Cloud Provider
• …

On a également des processus pour savoir si on a réalisé un bon call technique. Par exemple, il faut pouvoir répondre aux questions :

• Est-ce que j’ai compris leur infrastructure et les services utilisés ?
• Est-ce que j’ai compris leur architecture applicative ? Comment est gérée l’authentification ? Comment sont déployées les applications ? Quel est leur workflow Git ?
• Et surtout, qu’est-ce qui ne marche pas correctement chez le client ?
• Exemples: on est pas serein à chaque mise en production. On a des problèmes de performance sur notre backend.

Pour finir, il est important de faire de la veille technique pour se tenir à jour des nouvelles solutions ou fonctionnalités qui existent. On évolue dans un environnement où beaucoup de nouveaux concepts ou technologies sont créées, et on doit avoir une conviction forte sur chacune d’entre elles.

Ainsi, je suis abonné à quelques newsletters et il existe notamment celle de Padok qui est très riche en contenus ! 

Comme dans tout job, il existe des bons et mauvais côtés ! Ce qui est très intéressant en tant que Solution Architect, c’est de pouvoir être en première ligne avec les clients. Nous prenons pleinement part à la bonne compréhension de leurs enjeux et de leurs problématiques, et aux réflexions pour définir le meilleur accompagnement possible par Padok.

Ainsi, on voit beaucoup de choses, on développe d’autres compétences comme la communication, et c’est ce qui me plait en tant que profil tech.

En revanche, ce qui est frustrant parfois, c’est de ne pas pouvoir suivre le projet lorsqu’il est pris en charge par une équipe tech chez nous. On a moins de visibilité sur les choses qui sont faites, et la collaboration entre le client et Padok. Mais bon, c'est comme beaucoup de choses, il faut parfois savoir couper le cordon !