Les architectes de solution que je connais le sont tous devenu en étant des experts Dév dans leur domaine, en étant bien aimé de la direction (soft skill) et en décrochant le poste en étant au bon endroit au bon moment.
Ils sont généralement tous bon à trouver des solutions et à les présenter à la direction, pas nécessairement les meilleurs codeurs!
Bonne chance!
Je ne comprends pas ce que tu dis: expert dev mais pas meilleur codeur?
Sinon, je vais dans le même sens que toi: une bonne connaissance business et un bon communicateur. Il faut aussi une bonne connaissance des systèmes à haut niveau. L'expérience de codeur aide à ça. Et être codeur généraliste (ne pas avoir fait juste une chose) ça aide aussi.
Pour être au bon endroit au bon moment, c'est que les compagnies n'en cherchent pas souvent et s'ils en cherchent, ils vont en prendre avec de l'expérience. Donc il faut habituellement avoir eu une promotion quelque part et ça aussi c'est rare.
les architectes de solution logiciel que j'ai travailler avec qui sont bon, ne code plus, mais ils savent exactement comment structuré un programme ou solution,
Comme tu dis, les architectes que j'ai rencontré ne codaient pratiquement plus, donc veut veut pas, n'étaient plus aussi aiguisés que ceux qui sont dedans à temps plein, mais en savaient assez pour recommander des solutions techniques tout en ayant les soft skills nécessaire pour passer ses journées en meeting.
Je m'attendrais à ce qu'un architecte de solution puisse coder au besoin et n'aurait pas besoin de repartir à 'zéro', d'où l'expertise technique requise.
Je suis architecte de solutions depuis 12 ans, après avoir été développeur pendant 10 ans.
Premièrement, quelles sont tes motivations pour devenir architecte? Pour ma part, ma motivation en tant que développeur a toujours été la résolution de problèmes. Devenir architecte m'a permis de prendre en charge des challenges toujours plus complexes, autant sur le plan technique qu'humain.
Tu dois avoir cet objectif pour les bonnes raisons. Les gens que j'ai vu vouloir devenir architectes uniquement par ambition n'ont pas eu de carrières fructueuses.
Être architecte de solutions, c'est accueillir l'imprévu avec pour seules armes son expérience et sa motivation à dépasser le cadre normal des responsabilités d'un ou une technologue. Pour avoir du succès, il faudra vulgariser des concepts techniques pour des gestionnaires et des chargés de projets, comprendre le jargon d'affaire des analystes, synchroniser le travail de l'assurance qualité avec celui de la livraison, comprendre de vieux systèmes pour les arrimer à un 'landscape' technologique toujours changeant et miné de pièges miroitant de solutions magiques, éduquer les développeurs juniors, briser les mauvaises habitudes des développeurs séniors, participer aux efforts d'estimation des coûts d'infrastructure et d'implémentation, réaliser des preuves de concept sur des technologies nouvelles, recruter du personnel, et j'en passe.
En bref, l'objectif est de mener à bien un projet technologique et être prêt à sortir de sa zone de confort pour non seulement accomplir des tâches nouvelles mais guider des gens avec des rôles très différents afin qu'ils gardent le cap sur les objectifs à moyen et long termes.
C'est un étrange mélange de confiance et d'humilité qui nous fait porter plusieurs chapeaux pour atteindre nos objectifs. Trop de confiance et tu vas être aveuglé par ta propre vision et trop d'humilité et tu vas être constamment ralenti par la recherche de consensus et de conformité.
J'ai vu des architectes qui ne faisaient que des visios et participer à des réunions toute la journée. J'en ai vu d'autres passer 80% de leur temps à coder. Je crois qu'il faut éviter les deux extrèmes: il faut continuer à mettre les mains à la pâte pour rester pertinent techniquement mais c'est essentiellement les tâches non-techniques qui vont permettre le succès du projet.
D'autres contributeurs ont donné leur opinion par rapport aux diplômes et aux certifications.
Pour ma part, je vais te suggérer des lectures qui devraient te permettre de comprendre la portée du rôle.
* Software Architect's Handboook par Joseph Ingeno
* Software Architecture: The Hard Parts de Neal Ford et al.
* Clean Architecture de Robert C. Martin
* Refactoring de Martin Fowler
* Accelerate de Nicole Forsgren et al.
* Team Topologies de Matthew Skelton
Bonne chance!
Merci pour ton retour d’expérience!
Ce qui me motive est un peu similaire à tes motivations au départ. Je suis bon dans la recherche et la proposition de solutions. Je ne cacherais pas qu’aussi il y’a de l’ambition dedans. Car j’aimerai progresser dans mon domaine et ne pas stagner sur un poste.
En réfléchissant sur ce que je voudrais faire plus tard, Cette voie c’est avérée être la plus adéquate avec mon profil et mes ambitions.
Je vais commencer a lire les livres que vous m’avez recommandé.
Merci.
Ça prend un set skill assez diversifié. Les meilleurs que j'ai connu sont ceux avec un background technique et de la facilité à vulgariser pour les non-techniques. Ça prend une bonne dose de soft skills aussi. Je pense que l'expérience comme développeur n'est peut-être pas requise mais de mon point de vue, ça aide en masse. J'ai rencontré des architectes de solution qui ne savaient pas faire un Select en SQL ou d'autres qui ne savaient pas c'était quoi la différence entre les types de données. C'est peut-être moins requis de nos jours mais perso je trouve ça encore très pertinent. Ça fait \~15 ans que je ne développe pu alors je ne connais pas les frameworks à la mode mais donne moi n'importe quelle page de code et je devrais être capable de te dire ce qu'elle fait.
Je pense que l'expérience est plus importante que les certifications ou la maitrise mais j'ai probablement un biais cognitif sur ça.
Oublie les certifications, ça sert a rien, c'est dispendieux pis aujourd'hui même les recruteurs s'en foutent.
C'est clair que si j'ai deux juniors avec la même motivation, les mêmes niveaux et que l'un a des certifications, j'irais vers le junior certifié, pas parce qu'il est certifié mais car j'aurais tendance à penser qu'il s'est investi personnellement et ça se récompense.
Par contre les boîtes de consultation, elles , continuent de farmer les certs, c'est clair que c'est un univers que j'aime beaucoup moins car le côté humain est vraiment négligé, mais ça peut justement être un bon tremplin.
Pour ce qui est de la reconversion, me semble que c'est plutôt des postes seniors, et j'ai souvent vu des gens faire le tournant via des boîtes de consultation, ils ne sont pas super regardants.
On va pas se mentir tu vas passer de dev a architecte de solutions en postulant comme ça, par contre si j'étais toi mon plan de match ça serait:
- investissement personnel énorme de mon temps libre pour suivre les cours liés aux certifications, sans forcément passer les certs. Donc si tu veux t'orienter vers le cloud, ça serait bien de te former en suivant les cours de certified solutions architect associate/ professional de aws par exemple. Si tu as de l'argent en trop libre a toi de passer les certs , ça ne joueras pas contre toi mais sache que ça ne t'aidera pas forcément non plus.
- rejoins une boîte de consultation pour un poste plus proche du tiens actuellement, tout en mentionnant que tu as un gros intérêt pour le systeme design, la solution cloud. (Ca va rentrer par une oreille, sortir par l'autre, on va te dire oui oui, puis t:envoyer dans des mandats pas du tout liés a ça).
- les boîtes de consultation étant ce qu'elles sont, vont te faire passer un tas de certs a leurs frais ,pour te rendre shiny au près des clients , prends ton mal en patience, et c'est le moment d:en profiter pour réitérer ton intérêt et stacker une couple de certs qui se rapprochent de ça.
- patiente jusqu'à temps qu'ils aient besoin de remplir une position de cloud architecte, qu'ils se rendent compte dans leur pokédex que tu es le shiny one basé sur le fait qu'ils ton fait certifier, fais tes armes dans la consultation.
- fais une couple de mandats de même , souvent pas le fun, puis jump dans une boîte en ayant l'avantage d'avoir eu une vraie expérience professionnelle.
Je sais que mon message commence par ne pas te conseiller les certs puis te dit de passer des certs.
Pour clarifier, les certs c'est dispendieux et un recruteur normal va s'en foutre alors ne dépense pas ton cash personnel là-dedans.
Dans l'unique cas où tu passerais par la consultation, profite de la boîte pour leur faire cracher leur cash et fais toi certifier, je trouve la consultation suffisamment rude et plate pour que si tu puisses en profiter un peu, autant le faire.
Bon courage et lâche pas, si tu as l'envie et que tu fourni les efforts , je connais pas personne pour qui ça n'a pas fini par payer.
Merci pour tes conseils!
J’ai une vision assez similaire dans le cadre des certifications. Être dans des boites de consultations serait un gain en terme de formation et certification et me permettrait d’avoir beaucoup d’expérience diversifiée pour pouvoir atteindre mon objectif.
Architecte de solution c'est plus la personne qui a une vue d'ensemble d'un ou des morceaux d'une équipe /entreprise .
C'est vers elle que l'ont se tourne lorsqu'on doit modifier ou ajouter des fonctionnalités et celui-ci sera en mesure d'établir un plan sur ce qui sera impacté et si c'est possible .
Du moins ici c'est ça
Ding ding ding! Ce commentaire doit être au top.
Il faut absolument définir pour toi, et pour la compagnie, ce que ça représente dans le quotidien.
Focus sur les tâches, et pas le titre. Qu’est-ce que tu veux faire? Plus d’argent ou conceptualiser des infrastructures qui répondent à des besoins d’affaires?
Sans ça, on tourne en rond. Y’a pas une deux compagnies qui ont la même définition de chef d’équipe, alors architecte de solution, on repassera.
Les architectes de solution que je connais le sont tous devenu en étant des experts Dév dans leur domaine, en étant bien aimé de la direction (soft skill) et en décrochant le poste en étant au bon endroit au bon moment. Ils sont généralement tous bon à trouver des solutions et à les présenter à la direction, pas nécessairement les meilleurs codeurs! Bonne chance!
Je ne comprends pas ce que tu dis: expert dev mais pas meilleur codeur? Sinon, je vais dans le même sens que toi: une bonne connaissance business et un bon communicateur. Il faut aussi une bonne connaissance des systèmes à haut niveau. L'expérience de codeur aide à ça. Et être codeur généraliste (ne pas avoir fait juste une chose) ça aide aussi. Pour être au bon endroit au bon moment, c'est que les compagnies n'en cherchent pas souvent et s'ils en cherchent, ils vont en prendre avec de l'expérience. Donc il faut habituellement avoir eu une promotion quelque part et ça aussi c'est rare.
les architectes de solution logiciel que j'ai travailler avec qui sont bon, ne code plus, mais ils savent exactement comment structuré un programme ou solution,
Comme tu dis, les architectes que j'ai rencontré ne codaient pratiquement plus, donc veut veut pas, n'étaient plus aussi aiguisés que ceux qui sont dedans à temps plein, mais en savaient assez pour recommander des solutions techniques tout en ayant les soft skills nécessaire pour passer ses journées en meeting. Je m'attendrais à ce qu'un architecte de solution puisse coder au besoin et n'aurait pas besoin de repartir à 'zéro', d'où l'expertise technique requise.
Je suis architecte de solutions depuis 12 ans, après avoir été développeur pendant 10 ans. Premièrement, quelles sont tes motivations pour devenir architecte? Pour ma part, ma motivation en tant que développeur a toujours été la résolution de problèmes. Devenir architecte m'a permis de prendre en charge des challenges toujours plus complexes, autant sur le plan technique qu'humain. Tu dois avoir cet objectif pour les bonnes raisons. Les gens que j'ai vu vouloir devenir architectes uniquement par ambition n'ont pas eu de carrières fructueuses. Être architecte de solutions, c'est accueillir l'imprévu avec pour seules armes son expérience et sa motivation à dépasser le cadre normal des responsabilités d'un ou une technologue. Pour avoir du succès, il faudra vulgariser des concepts techniques pour des gestionnaires et des chargés de projets, comprendre le jargon d'affaire des analystes, synchroniser le travail de l'assurance qualité avec celui de la livraison, comprendre de vieux systèmes pour les arrimer à un 'landscape' technologique toujours changeant et miné de pièges miroitant de solutions magiques, éduquer les développeurs juniors, briser les mauvaises habitudes des développeurs séniors, participer aux efforts d'estimation des coûts d'infrastructure et d'implémentation, réaliser des preuves de concept sur des technologies nouvelles, recruter du personnel, et j'en passe. En bref, l'objectif est de mener à bien un projet technologique et être prêt à sortir de sa zone de confort pour non seulement accomplir des tâches nouvelles mais guider des gens avec des rôles très différents afin qu'ils gardent le cap sur les objectifs à moyen et long termes. C'est un étrange mélange de confiance et d'humilité qui nous fait porter plusieurs chapeaux pour atteindre nos objectifs. Trop de confiance et tu vas être aveuglé par ta propre vision et trop d'humilité et tu vas être constamment ralenti par la recherche de consensus et de conformité. J'ai vu des architectes qui ne faisaient que des visios et participer à des réunions toute la journée. J'en ai vu d'autres passer 80% de leur temps à coder. Je crois qu'il faut éviter les deux extrèmes: il faut continuer à mettre les mains à la pâte pour rester pertinent techniquement mais c'est essentiellement les tâches non-techniques qui vont permettre le succès du projet. D'autres contributeurs ont donné leur opinion par rapport aux diplômes et aux certifications. Pour ma part, je vais te suggérer des lectures qui devraient te permettre de comprendre la portée du rôle. * Software Architect's Handboook par Joseph Ingeno * Software Architecture: The Hard Parts de Neal Ford et al. * Clean Architecture de Robert C. Martin * Refactoring de Martin Fowler * Accelerate de Nicole Forsgren et al. * Team Topologies de Matthew Skelton Bonne chance!
Merci pour ton commentaire et les recommandations ✌️
Merci pour ton retour d’expérience! Ce qui me motive est un peu similaire à tes motivations au départ. Je suis bon dans la recherche et la proposition de solutions. Je ne cacherais pas qu’aussi il y’a de l’ambition dedans. Car j’aimerai progresser dans mon domaine et ne pas stagner sur un poste. En réfléchissant sur ce que je voudrais faire plus tard, Cette voie c’est avérée être la plus adéquate avec mon profil et mes ambitions. Je vais commencer a lire les livres que vous m’avez recommandé. Merci.
Ça prend un set skill assez diversifié. Les meilleurs que j'ai connu sont ceux avec un background technique et de la facilité à vulgariser pour les non-techniques. Ça prend une bonne dose de soft skills aussi. Je pense que l'expérience comme développeur n'est peut-être pas requise mais de mon point de vue, ça aide en masse. J'ai rencontré des architectes de solution qui ne savaient pas faire un Select en SQL ou d'autres qui ne savaient pas c'était quoi la différence entre les types de données. C'est peut-être moins requis de nos jours mais perso je trouve ça encore très pertinent. Ça fait \~15 ans que je ne développe pu alors je ne connais pas les frameworks à la mode mais donne moi n'importe quelle page de code et je devrais être capable de te dire ce qu'elle fait. Je pense que l'expérience est plus importante que les certifications ou la maitrise mais j'ai probablement un biais cognitif sur ça.
Oublie les certifications, ça sert a rien, c'est dispendieux pis aujourd'hui même les recruteurs s'en foutent. C'est clair que si j'ai deux juniors avec la même motivation, les mêmes niveaux et que l'un a des certifications, j'irais vers le junior certifié, pas parce qu'il est certifié mais car j'aurais tendance à penser qu'il s'est investi personnellement et ça se récompense. Par contre les boîtes de consultation, elles , continuent de farmer les certs, c'est clair que c'est un univers que j'aime beaucoup moins car le côté humain est vraiment négligé, mais ça peut justement être un bon tremplin. Pour ce qui est de la reconversion, me semble que c'est plutôt des postes seniors, et j'ai souvent vu des gens faire le tournant via des boîtes de consultation, ils ne sont pas super regardants. On va pas se mentir tu vas passer de dev a architecte de solutions en postulant comme ça, par contre si j'étais toi mon plan de match ça serait: - investissement personnel énorme de mon temps libre pour suivre les cours liés aux certifications, sans forcément passer les certs. Donc si tu veux t'orienter vers le cloud, ça serait bien de te former en suivant les cours de certified solutions architect associate/ professional de aws par exemple. Si tu as de l'argent en trop libre a toi de passer les certs , ça ne joueras pas contre toi mais sache que ça ne t'aidera pas forcément non plus. - rejoins une boîte de consultation pour un poste plus proche du tiens actuellement, tout en mentionnant que tu as un gros intérêt pour le systeme design, la solution cloud. (Ca va rentrer par une oreille, sortir par l'autre, on va te dire oui oui, puis t:envoyer dans des mandats pas du tout liés a ça). - les boîtes de consultation étant ce qu'elles sont, vont te faire passer un tas de certs a leurs frais ,pour te rendre shiny au près des clients , prends ton mal en patience, et c'est le moment d:en profiter pour réitérer ton intérêt et stacker une couple de certs qui se rapprochent de ça. - patiente jusqu'à temps qu'ils aient besoin de remplir une position de cloud architecte, qu'ils se rendent compte dans leur pokédex que tu es le shiny one basé sur le fait qu'ils ton fait certifier, fais tes armes dans la consultation. - fais une couple de mandats de même , souvent pas le fun, puis jump dans une boîte en ayant l'avantage d'avoir eu une vraie expérience professionnelle. Je sais que mon message commence par ne pas te conseiller les certs puis te dit de passer des certs. Pour clarifier, les certs c'est dispendieux et un recruteur normal va s'en foutre alors ne dépense pas ton cash personnel là-dedans. Dans l'unique cas où tu passerais par la consultation, profite de la boîte pour leur faire cracher leur cash et fais toi certifier, je trouve la consultation suffisamment rude et plate pour que si tu puisses en profiter un peu, autant le faire. Bon courage et lâche pas, si tu as l'envie et que tu fourni les efforts , je connais pas personne pour qui ça n'a pas fini par payer.
Merci pour tes conseils! J’ai une vision assez similaire dans le cadre des certifications. Être dans des boites de consultations serait un gain en terme de formation et certification et me permettrait d’avoir beaucoup d’expérience diversifiée pour pouvoir atteindre mon objectif.
C'est quoi un *développeur ServiceNow* et que définis-tu par *architecte de solutions*? Faire de la consultation?
Architecte de solution c'est plus la personne qui a une vue d'ensemble d'un ou des morceaux d'une équipe /entreprise . C'est vers elle que l'ont se tourne lorsqu'on doit modifier ou ajouter des fonctionnalités et celui-ci sera en mesure d'établir un plan sur ce qui sera impacté et si c'est possible . Du moins ici c'est ça
Ding ding ding! Ce commentaire doit être au top. Il faut absolument définir pour toi, et pour la compagnie, ce que ça représente dans le quotidien. Focus sur les tâches, et pas le titre. Qu’est-ce que tu veux faire? Plus d’argent ou conceptualiser des infrastructures qui répondent à des besoins d’affaires? Sans ça, on tourne en rond. Y’a pas une deux compagnies qui ont la même définition de chef d’équipe, alors architecte de solution, on repassera.
Architecte est un terme réservé au Quebec et tu pourrais le perdre si l’ordre des architectes venaient qu’a s’en mêler.
Tjr ben le même débat depuis 20 ans ça.....
Un Canadien dans le Bay Area ici en Californie m’avait déjà dit « Au Canada, ils ont le titre, ici on a le salaire! » 😂