Je pense que la meilleure définition (la plus pratique et la plus précise) de l'"architecture" est "ce à quoi vous pensez lorsque vous réfléchissez à votre problème actuel d'une manière utilement plus abstraite". Ou, pour le dire autrement, cela peut être une analogie avec le vieux dicton qui dit que l'on gagne la bataille mais que l'on perd la guerre. Les programmeurs gagnent les batailles, les architectes gagnent la guerre.
Parler d'architecture logicielle est glissant, car la définition de l'architecture logicielle elle-même est glissante et change en fonction de qui vous demandez, et quand. Un descripteur avec lequel la plupart des gens seraient d'accord est " les architectes regardent la situation dans son ensemble. "
À une extrémité du spectre se trouve un CTO ou un CIO pour qui l'architecture consiste à savoir dans quelles technologies et plateformes l'entreprise doit investir.
À l'autre extrémité, même un programmeur ordinaire Joe/Jane pense à la façon dont les pièces du système sur lequel il travaille vont ensemble.
Entre les deux, l'équipe de ce programmeur pourrait avoir un architecte qui passe sa journée à s'assurer :
- que l'équipe adopte la bonne approche générale pour résoudre le problème ;
- que les différents sous-systèmes sur lesquels les programmeurs travaillent s'imbriqueront bien lorsqu'ils les mettront ensemble ;
- que l'équipe résout le bon problème (selon la culture et la taille de l'organisation, cela pourrait être ventilé dans un rôle différent).
Cela peut impliquer beaucoup de diagrammes UML, ou cela peut être plus pratique et impliquer plus de discussions et de tableaux blancs, selon encore une fois la culture et la taille de l'organisation.
S'il s'agit d'un bon groupe de développement de logiciels, je m'attendrais à ce que ces discussions impliquent les membres de l'équipe de projet à tous les niveaux, mais dans les groupes plus moyens, il pourrait y avoir plus de formalités et des lignes de division plus strictes, et l'architecte pourrait passer la plupart de son temps avec les chefs de projet, les planificateurs de projet, les chefs d'équipe, etc.
Dans les grands contextes organisationnels, il est fréquent que l'on insiste beaucoup sur les formalismes pour protéger les travailleurs de rang des distractions. Dans les petites organisations, ou les groupes de dév plus pointus dans les grandes organisations, il est plus facile de garder la collaboration du travail d'équipe de devenir une distraction (et parfois plus facile de convaincre la direction que vous savez lequel est lequel).
Il pourrait y avoir un architecte au niveau supérieur qui pense à la façon dont les différents systèmes d'entreprise fonctionnent ensemble.
Il y a un terme qui revient parfois dans les discussions sur les logiciels, mais étonnamment, je ne pense pas l'avoir jamais vu dans une discussion sur l'architecture : les préoccupations transversales.
Les préoccupations transversales sont des questions qui traversent l'ensemble de l'application, comme la journalisation, la sécurité, la façon dont les données circulent (files de messages vs écouteurs d'événements vs, etc), et ainsi de suite. Les programmeurs pensent certainement à ces choses et à la façon dont elles sont liées aux parties du projet sur lesquelles ils travaillent. Mais il serait également raisonnable de dire que les préoccupations transversales sont (ou sont une bonne partie de) la viande et la boisson de l'architecte.
Aussi, comme le dit un dicton militaire un peu plus obscur, "les soldats étudient la tactique, les généraux la logistique":
La nature du rôle de l'architecte est telle qu'il passe beaucoup de temps à traiter avec tous les membres et niveaux de l'équipe, y compris le planificateur de projet, et le chef de projet (s'ils ne sont pas la même personne). Comme je l'ai mentionné plus haut, si je ne serais pas du tout surpris qu'une organisation donnée soit très formelle en ce qui concerne les limites entre les domaines de responsabilité, je ne serais pas non plus du tout surpris que ce soit l'inverse, c'est-à-dire que le chef de projet, l'architecte du projet et tous les autres passent beaucoup de temps non seulement à se concerter, mais aussi à collaborer et à bavarder. D'où le fait que l'architecte pourrait aussi finir par faire beaucoup de choses pratiques avec la planification de projet et la méthodologie de développement de logiciels.
(Note, là où j'écris "programmeur", insérez votre titre préféré : développeur, ingénieur, etc. Certaines personnes (et quelques organisations) tentent d'inventer une hiérarchie autour de ces titres, mais personne ne semble avoir les mêmes définitions, de sorte que la distinction n'a pas de sens.)
L'architecte est un professionnel de l'informatique.