En déchiffrant les registres de l’histoire informatique, on note l’évolution des architectures logicielles du modèle « Single Tier » vers le modèle « 2-Tiers » et de ce dernier vers le modèle « n-Tiers ».
Si l’évolution vers l’architecture « 2-Tiers » (dite encore client/serveur) fut imposée par le développement spectaculaire des réseaux et de l’interconnexion et par le souci d’isoler la couche données, le passage vers les architectures « n-Tiers » a été exigé par l’explosion de la bulle Internet et la volonté de séparer la couche métier de la couche présentation.
Ces mutations, qualifiées de métamorphoses, ont eu des retombées directes sur les ressources humaines nécessaires pour la réalisation d’un projet informatique. D’ailleurs, afin d’assurer la bonne conduite d’un projet J2EE ou dotNET (les deux plateformes qui implémentent l’architecture « n-Tiers »), pas moins de onze profils sont nécessaires. Il s’agit de : un Architecte Logiciels, un chef de projet, un analyste métier, un layout designer, un développeur de la couche présentation, un développeur des composants métier, un concepteur de données, un administrateur de base de données, un spécialiste en migration des données, un spécialiste d’infrastructure et un spécialiste de tests et de benchmarking.
Intéressons nous à l’Architecte Logiciels. Définissons le à travers ses fonctions et ses tâches.
Dans la suite, nous restreindrons notre discours à la plate-forme J2EE et nous tâcherons d’énumérer les différentes attributions d’un Architecte Logiciels.
Primo, un architecte logiciel identifie les technologies susceptibles d’être utilisées pour un projet. Il s’avère intéressant de signaler que plusieurs sont les organisations où les choix techniques sont pris au niveau décisionnel (ou pilotage). Nous citons, le choix du matériel, du système d’exploitation et du vendeur du conteneur J2EE et du langage de programmation. De ce fait, le choix du Java comme langage de programmation peut être pris au niveau décisionnel pour assurer l’hétérogénéité des plate-formes et la simplicité de l’interopérabilité entre les applications communicantes ; mais, le choix du parseur XML à utiliser est du ressort des architectes logiciels de chacune des applications à développer.
Secondo, c’est à l’architecte logiciel de recommander l’adoption d’une telle méthode de développement et l’utilisation d’un tel framework J2EE. Ces choix sont d’une importance cruciale dans le sens qu’ils agissent directement sur les délais, le coût et la qualité de l’application à développer. A ce stade, un prototypage réfléchi et ciblé est exigé.
Tertio, l’architecte logiciel fixe la conception générale de l’application, cerne sa structure et veille à son homogénéité. D’ailleurs, les habitudes, les opinions et les préférences des développeurs sont à capitaliser et à canaliser de façon à aboutir à un travail complémentaire.
En outre, l’architecte logiciel coordonne avec le chef de projet et l’analyste métier (le business analyst) pour déterminer les traitements métier à implémenter. Il vérifie, également, que la conception de l’application est correctement documentée et que le code écrit par les développeurs est conforme aux guides de codage qu’il a établis.
D’autres part, étant plus expérimenté que l’ensemble des développeurs, c’est à l’architecte d’aider ces derniers à résoudre les difficultés d’implémentation qu’ils rencontrent.
Last but not Least, l’architecte logiciel identifie les tâches à implémenter et les présente au chef de projet tout en lui assistant à la planification et à l’estimation des délais. Ce rôle est capital pour le cas des projets J2EE du fait que cette plate-forme regroupe un nombre élevé de technologies et de moyens (protocoles, langages, composants, utilitaires et règles) que le chef de projet y est, généralement, ignorant ou peu familier.
Toujours côté managérat, l’avis de l’architecte logiciel lors de l’affectation des ressources humaines à consacrer à un projet J2EE est aussi important, voire plus important, que l’avis du chef de projet. En effet, l’architecte logiciel est la personne la mieux placée pour attester le niveau technique d’un développeur ou estimer les marges d’évolution d’un potentiel à caractère technocrate. Il est évident qu’une erreur d’affectation porte de sérieux préjudices à l’ensemble du projet : un projet J2EE est une chaîne dont la faiblesse au niveau d’un maillon influe sur le reste.La complexité technique qu’impose un projet J2EE, qualifiée d’ores et déjà d’usine à gaz, nous donne l’illusion de croire que le chef de projet a perdu son poids au sein du projet en faveur de l’architecte logiciel. Ceci est, totalement, erroné du fait que le chef de projet reste le premier responsable de la coordination entre les différentes parties intervenantes au projet et de la planification des tâches. Il est, également, responsable du suivi et de la communication de l’état d’avancement du projet à la comité de pilotage aussi bien qu’aux utilisateurs finaux de l’application à développer. De plus, il est de son ressort d’ordonner l’acquisition de toute ressource matérielle ou logicielle nécessaire pour la réalisation du projet qu’il chapeaute. En définitive, la collaboration entre chef de projet et architecte logiciels est cruciale. C’est à l’architecte d’assister, de conseiller et de guider le chef de projet sur toutes les questions d’ordre technique et c’est au chef de projet d’orchestrer l’ensemble.
Si l’évolution vers l’architecture « 2-Tiers » (dite encore client/serveur) fut imposée par le développement spectaculaire des réseaux et de l’interconnexion et par le souci d’isoler la couche données, le passage vers les architectures « n-Tiers » a été exigé par l’explosion de la bulle Internet et la volonté de séparer la couche métier de la couche présentation.
Ces mutations, qualifiées de métamorphoses, ont eu des retombées directes sur les ressources humaines nécessaires pour la réalisation d’un projet informatique. D’ailleurs, afin d’assurer la bonne conduite d’un projet J2EE ou dotNET (les deux plateformes qui implémentent l’architecture « n-Tiers »), pas moins de onze profils sont nécessaires. Il s’agit de : un Architecte Logiciels, un chef de projet, un analyste métier, un layout designer, un développeur de la couche présentation, un développeur des composants métier, un concepteur de données, un administrateur de base de données, un spécialiste en migration des données, un spécialiste d’infrastructure et un spécialiste de tests et de benchmarking.
Intéressons nous à l’Architecte Logiciels. Définissons le à travers ses fonctions et ses tâches.
Dans la suite, nous restreindrons notre discours à la plate-forme J2EE et nous tâcherons d’énumérer les différentes attributions d’un Architecte Logiciels.
Primo, un architecte logiciel identifie les technologies susceptibles d’être utilisées pour un projet. Il s’avère intéressant de signaler que plusieurs sont les organisations où les choix techniques sont pris au niveau décisionnel (ou pilotage). Nous citons, le choix du matériel, du système d’exploitation et du vendeur du conteneur J2EE et du langage de programmation. De ce fait, le choix du Java comme langage de programmation peut être pris au niveau décisionnel pour assurer l’hétérogénéité des plate-formes et la simplicité de l’interopérabilité entre les applications communicantes ; mais, le choix du parseur XML à utiliser est du ressort des architectes logiciels de chacune des applications à développer.
Secondo, c’est à l’architecte logiciel de recommander l’adoption d’une telle méthode de développement et l’utilisation d’un tel framework J2EE. Ces choix sont d’une importance cruciale dans le sens qu’ils agissent directement sur les délais, le coût et la qualité de l’application à développer. A ce stade, un prototypage réfléchi et ciblé est exigé.
Tertio, l’architecte logiciel fixe la conception générale de l’application, cerne sa structure et veille à son homogénéité. D’ailleurs, les habitudes, les opinions et les préférences des développeurs sont à capitaliser et à canaliser de façon à aboutir à un travail complémentaire.
En outre, l’architecte logiciel coordonne avec le chef de projet et l’analyste métier (le business analyst) pour déterminer les traitements métier à implémenter. Il vérifie, également, que la conception de l’application est correctement documentée et que le code écrit par les développeurs est conforme aux guides de codage qu’il a établis.
D’autres part, étant plus expérimenté que l’ensemble des développeurs, c’est à l’architecte d’aider ces derniers à résoudre les difficultés d’implémentation qu’ils rencontrent.
Last but not Least, l’architecte logiciel identifie les tâches à implémenter et les présente au chef de projet tout en lui assistant à la planification et à l’estimation des délais. Ce rôle est capital pour le cas des projets J2EE du fait que cette plate-forme regroupe un nombre élevé de technologies et de moyens (protocoles, langages, composants, utilitaires et règles) que le chef de projet y est, généralement, ignorant ou peu familier.
Toujours côté managérat, l’avis de l’architecte logiciel lors de l’affectation des ressources humaines à consacrer à un projet J2EE est aussi important, voire plus important, que l’avis du chef de projet. En effet, l’architecte logiciel est la personne la mieux placée pour attester le niveau technique d’un développeur ou estimer les marges d’évolution d’un potentiel à caractère technocrate. Il est évident qu’une erreur d’affectation porte de sérieux préjudices à l’ensemble du projet : un projet J2EE est une chaîne dont la faiblesse au niveau d’un maillon influe sur le reste.La complexité technique qu’impose un projet J2EE, qualifiée d’ores et déjà d’usine à gaz, nous donne l’illusion de croire que le chef de projet a perdu son poids au sein du projet en faveur de l’architecte logiciel. Ceci est, totalement, erroné du fait que le chef de projet reste le premier responsable de la coordination entre les différentes parties intervenantes au projet et de la planification des tâches. Il est, également, responsable du suivi et de la communication de l’état d’avancement du projet à la comité de pilotage aussi bien qu’aux utilisateurs finaux de l’application à développer. De plus, il est de son ressort d’ordonner l’acquisition de toute ressource matérielle ou logicielle nécessaire pour la réalisation du projet qu’il chapeaute. En définitive, la collaboration entre chef de projet et architecte logiciels est cruciale. C’est à l’architecte d’assister, de conseiller et de guider le chef de projet sur toutes les questions d’ordre technique et c’est au chef de projet d’orchestrer l’ensemble.
Avec toutes ces attributions, le chef de projet perd du terrain au faveur de l'architect ou, au mieux, disons que le chef de projet s'oriente de plus en plus vers les spécifications du métier... En tout cas, je pense que ceci dépend largement des administrations.
ReplyDeleteVery good effort ! You have covered many parts of the software architect responsabilities; also, I appreciate the distinction between the project manager and the software architect fonctions. But, I think that all this depends a lot on the organisational and logistic rules in every company.
ReplyDeleteSi le développement informatique peut être simulé à un match de foot, les développeurs sont les joueurs, le chef de projet est le coach et l'architecte est certainement l'arbitre (d'après l'article, il veille au respect des normes)
ReplyDeletec'est un article simple et clair , j'ai tout compris.je suis entièrement d'accord avec vous. mes félicitations.
ReplyDeletec'est un article simple et clair , j'ai tout compris.je suis entièrement d'accord avec vous. mes félicitations.
ReplyDeleteBien que les moyens et les outils qui permettent de la simplifier existent, la J2EE reste un vrai challenge. En J2EE, comme les résultats n’apparaissent qu’à la fin du cycle de développement, le rôle de l’architecte est primordial. En quelques sorte c’est un garant de la validité de l’architecture et de la validité des processus adoptés. Le chef de projet est, désormais, incapable de le remplacer. Mais une collaboration entre architecte et chef de projet est plus que nécessaire.
ReplyDeleteIl est vrai que l’architecte gagne de plus en plus du terrain au détriment du chef de projet : les chefs de projets aujourd’hui sont des cobolistes et des architectes grands systèmes. Donc, le help d’un architecte est indispensable.