Meilleure réponse
Il n’existe pas de définitions formelles de ces rôles qui sont largement adoptées comme norme par organisations, il y aura donc beaucoup de variation et de contexte localisé.
Comme guide général, jutilise les définitions suivantes:
- Architecte technique – Un spécialiste des domaines alignés aux infrastructures, aux réseaux et à la sécurité.
- Architecte de solutions – Un généraliste responsable des solutions basées sur des projets qui prennent en compte tous les aspects d’une solution (par exemple, l’impact commercial, les changements d’applications, les données et les informations et la technologie qui sous-tend tout cela) et, espérons-le, les considérations des clients également.
- Architecte principal – Quelquun avec un ensemble de responsabilités plus large que les rôles ci-dessus. Cela peut être axé sur un domaine dactivité, un programme de travail plus large ou lensemble dune entreprise. Il est également souvent utilisé par les cabinets de conseil pour suggérer un niveau de supériorité (dexpérience) par rapport aux autres architectes de léquipe. Ils auront normalement des préoccupations généralistes plutôt que de se concentrer sur un seul domaine darchitecture tel que linfrastructure, mais ce nest pas toujours le cas.
Jespère que cela aide. Il est important de se rappeler quil y a pas de normes acceptées, donc les termes eux-mêmes sont spécifiques à lenvironnement dans lequel ils sont utilisés.
Réponse
Premièrement, il est important de différencier larchitecture logicielle des bonnes pratiques. Un bon ingénieur logiciel peut être excellent en codage, excellent et détaillé dans son approche, et avoir une bonne compréhension du problème, mais peut ne pas être un bon architecte.
Au minimum, un bon Larchitecte doit avoir les compétences suivantes:
Un architecte est excellent pour la décomposition des problèmes . La décomposition des problèmes est la compétence nécessaire pour voir un problème à pratiquement nimporte quel niveau et le décomposer en étapes et en éléments nécessaires pour le mettre en œuvre. Un bon architecte logiciel peut accepter une déclaration comme « Nos systèmes de contrôle du trafic aérien sont inadéquats et nous avons besoin dune meilleure conception » et connaît les questions à poser pour commencer à décomposer le problème en composants réalisables, pour décomposer ces objectifs en sous-projets réalisables , et décomposer ces sous-projets en tâches de programmation réalisables. Un bon architecte peut faire ces choses à nimporte quel niveau ou à nimporte quelle échelle, de la conception dun projet logiciel dun milliard de lignes à la compréhension de la meilleure façon dimplémenter un algorithme pour gérer des liens non fiables. Léchelle na pas dimportance car le processus est toujours le même.
Un architecte comprend les interfaces . Les interfaces, que ce soit sous la forme de protocoles, de bibliothèques de fonctions, dinterfaces de classes ou de schémas, sont le principal outil nécessaire pour gérer la complexité des projets lorsquil existe des entrepreneurs et des implémenteurs indépendants. En connaissant le processus de définition dinterfaces nettes, sans ambiguïté et logiquement complètes, un architecte peut permettre à de nombreuses personnes de créer des éléments de systèmes qui se connectent facilement pour atteindre un objectif plus large.
Un architecte comprend que la complexité est lennemi et maîtrise les outils de programmation et les paradigmes nécessaires pour réduire la complexité de tous les composants, réduire la complexité des interfaces et assurer une redondance minimale ou nulle de la mise en œuvre de la fonction. Ils peuvent rapidement reconnaître les algorithmes et les implémentations trop spécifiques ou trop génériques, et guider ceux qui développent pour créer des composants qui remplissent exactement la bonne fonction. Souvent, les outils de gestion de la complexité sont des éléments tels que le masquage des données, la programmation orientée objet, les systèmes dauto-validation et les plans de test complets pour les interfaces standard. Mais un bon architecte nest pas dogmatique à propos des outils et des technologies, car il a une compréhension académique complète des fondements et des raisons pour lesquels le masquage des données fonctionne, et pourquoi certains langages prennent en charge de bons principes de conception et dautres pas.
Un larchitecte est un bon communicateur, un bon écrivain et documenteur prolifique , et il parle le langage de programmation ainsi que le langage commun de ceux qui sont parties prenantes dans la conception du système. Avec une bonne communication, un bon architecte peut donner des raisons concrètes pour les pratiques de programmation plutôt que des opinions, et offre un aperçu à son équipe plutôt que des arguments. Ils favorisent fortement et recherchent lopinion de lutilisateur sur laptitude à celui de leurs propres ou des programmeurs impliqués dans le projet.
Un bon architecte est un bon leader et est excellent pour gagner le respect de tous les techniciens ils travaillent avec .Cela signifie généralement quils ont un haut niveau de compétence, ont travaillé dans plusieurs langues et ont déjà été architectes, ou ont démontré leur capacité à créer des conceptions de systèmes qui sont restées flexibles face au changement.
De nombreuses définitions incluent un éventail de mots à la mode, mettant laccent sur des méthodologies telles que la conception axée sur les données, la programmation agile, des langages, des plates-formes et des boîtes à outils spécifiques. actuellement en vogue. Ainsi, à bien des égards, les principales compétences dun architecte sont lexpérience, lintelligence, la volonté de travailler dur et dassumer un rôle pratique, une bonne intuition et la capacité de résoudre les problèmes en utilisant la logique de sorte quà mesure que les mots à la mode de lindustrie vont et viennent, leurs conceptions restent utiles et pertinentes.
Ma définition ci-dessus ninclut pas intentionnellement les compétences en gestion de projet, en planification et en gestion. Le rôle de larchitecte est de créer de bons systèmes et non de résoudre les problèmes déquipe ou les budgets. En fait, il est préférable que ceux qui ont des budgets et des problèmes déquipe soient simplement des parties prenantes qui aident à définir lune des contraintes auxquelles larchitecte doit faire face, tout comme si cela faisait partie de leur problème de conception.