Peut-être que je suis présenté comme "architecte logiciel" aux clients parce que tous les autres préfèrent ne pas être l'objet de la colère que le client est prêt à déchaîner. (Les clients ne viennent pas souvent me voir quand tout va bien.)
En tout cas, pour certaines parties du logiciel que mon groupe développe, je suis probablement ce qui se rapproche le plus d'un "architecte logiciel". C'est un peu une description de poste nébuleuse ou peut-être bidon, comme mentionné par d'autres réponses. Mon vrai titre est ingénieur principal. Possiblement aussi bidon.
Je pense que devenir un "architecte logiciel" nécessite effectivement beaucoup d'expérience avec votre propre logiciel, ainsi qu'une compréhension du fonctionnement d'autres logiciels similaires. Cette expérience et cette compréhension n'arrivent pas toutes seules, même si vous travaillez sur le même domaine pendant 20+ ans. Je pense qu'il y a une attitude que vous devez avoir envers votre carrière qui comprend :
- Vous devez vouloir comprendre toutes les petites pièces du produit - pas seulement savoir qu'elles existent, mais comprendre leur mise en œuvre, leurs limites, la dette technique, etc. associée à chaque partie du système.
- Vous devez apprendre comment il interagit avec les autres logiciels - les logiciels que vous écrivez et les logiciels complémentaires, et les logiciels des concurrents.
- Vous devriez comprendre comment vos clients utilisent le logiciel, et aussi ce dont ils ont besoin.
Vous pouvez travailler dans la même entreprise pendant 20 ans et ne rien réaliser de ce qui précède, donc vous avez besoin de plus que du temps.
La meilleure façon de faire #1 est d'acquérir de l'expérience en faisant du développement sur autant de pièces du logiciel que vous pouvez. Corrigez les bugs, aidez aux fonctionnalités, parlez aux développeurs qui possèdent chacune des pièces. Comprendre la "dette technique" associée à tous les éléments vous aidera à comprendre combien de temps il faudra pour modifier quelque chose, combien de bogues il y aura, et quand il sera temps de le réécrire. S'il existe plusieurs solutions, celle qui implique de gros changements dans le code avec beaucoup de dette technique est probablement plus risquée et celle dont il faut s'éloigner.
Une bonne façon d'apprendre le #2 ci-dessus est d'utiliser le logiciel vous-même.
La meilleure façon d'accomplir le #3 ci-dessus est de parler aux clients, de leur rendre visite et de les regarder utiliser l'outil. Il y a une tendance, je pense, pour les développeurs de logiciels à être isolés des clients, à vivre dans leur propre monde où ils pensent comprendre ce que le client veut, pourquoi il le veut et comment le lui donner. Chaque fois que j'interagis avec une personne qui utilise réellement le logiciel, c'est une expérience révélatrice et, souvent, cela me pousse à repenser les fonctionnalités existantes ou me donne des idées pour en créer de nouvelles.
.