Mieux définir les métiers d’architectes

Dans le monde des systèmes d’information, le terme « architecte » suscite souvent la confusion, voire même une certaine perplexité quant au rôle et aux attributions de ceux que l’on nomme ainsi. Cette confusion vient certainement du fait qu’il faudrait en réalité distinguer au moins trois spécialités et donc toujours faire suivre le terme « architecte » d’un qualificatif plus précis.

Bien qu’ils aient des attributions différentes au sein du SI, l’architecte fonctionnel, l’architecte réseau et l’architecte logiciel ont en commun un certain nombre d’objectifs et d’attributions. En ce qui concerne leurs objectifs, tous trois sont des hommes d’ensemble et de durée, les garants de la cohérence et de la pérennité.

Le rôle des architectes

Les projets

Les architectes considèrent les projets (site web, déploiement ERP, …), non pas comme un aboutissement mais comme une étape du cycle de vie du SI. Ils interviennent donc en amont pour aider la maîtrise d’ouvrage et la maîtrise d’œuvre dans les choix technologiques en cohérence avec l’existant puis restent présents en support tout au long du projet afin de répondre aux différentes questions qui peuvent se poser. Au moment du déploiement, ils transmettent, avec le chef de projet, les différentes compétences utiles pour les exploitants en charge du bon fonctionnement des applications. Ils valident, avec la maîtrise d’ouvrage, les procédures d’exploitation proposées et peuvent éventuellement auditer leur mise en œuvre ou valider l’utilisation des indicateurs adéquats.

L’exploitation

Au delà des évolutions fonctionnelles, le SI est souvent le théâtre de modifications liées au cycle de vie des applications et progiciels utilisés. L’apparition d’une nouvelle version de la JVM, la fin de garantie d’un système d’exploitation, la sortie d’un patch de sécurité pour un logiciel ou les fonctionnalités offertes par la dernière génération de routeurs CISCO nécessitent généralement une phase de réflexion avant toute mise en œuvre. Les architectes prennent donc en charge une analyse d’impact qui, en fonction des contraintes liées à l’utilisation (disponibilité et qualité de service) et à la complexité technique, permet de concevoir un plan de migration (procédure et planification).

Mais l’interaction quotidienne entre le SI et ses utilisateurs peut aussi parfois avoir un impact sur l’utilisation des ressources et nécessiter une réaction de la part des architectes. Ainsi, le succès grandissant d’une application peut provoquer une saturation du segment de réseau sur lequel elle est hébergée (gros volumes de données) ou épuiser les ressources CPU et mémoire des serveurs qui l’accueillent (gros volumes de calcul, par exemple data warehouse). Là encore les architectes interviennent pour adapter le dimensionnement des ressources à l’utilisation réelle.

La cartographie

La cartographie du système d’information est le premier outil des architectes puisqu’elle leur permet de maintenir un « état des lieux » des applications, des outils et des flux et leur fournit le support du lien entre fonctionnalités et technologies. En effet la cartographie se lit généralement sur plusieurs niveaux (métier, logique, applicative, technique), le premier orienté vers les utilisateurs exclut tout acronyme technique pour ne recenser que les fonctionnalités métiers, alors que le dernier détaille, avec numéros de version à l’appui, toutes les caractéristiques techniques de chacune des applications. C’est cette cartographie qui regroupe les aspects fonctionnels et techniques, permet d’évaluer l’impact d’un changement au sein du SI et appuie donc toutes les perspectives d’évolutions technologiques amenées par une veille active.

La veille technologique

La veille technologique est indispensable aux architectes qui doivent prévoir les évolutions du SI pour assurer la cohérence entre les différentes générations d’outils (matériels, logiciels) et planifier la migration lorsque l’un de ces outils arrive en fin de vie.

Elle leur permet d’évaluer au travers de prototypes ou de projets pilotes les opportunités technologiques et les mettre en relation avec les besoins exprimés par les utilisateurs.

La place des architectes dans l’organisation

On voit donc au travers de leurs attributions que les architectes ne sont pas seulement des techniciens mais plutôt des technologues à qui l’on demande d’être capables d’anticiper à la fois l’évolution des technologies et les besoins des utilisateurs. Cette capacité d’anticipation et leur positionnement transverse auprès des chefs de projets, de la maîtrise d’ouvrage et des exploitants leur permet de faire respecter les grandes lignes stratégiques de la Direction du Système d’Information, grandes lignes qu’ils ont généralement contribué à élaborer.

Cependant ces compétences de technologues ne doivent pas masquer l’importance du lien qu’ils maintiennent entre fonctionnel et technique. En effet, s’ils savent expliquer comment sont implémentés les processus métiers de l’entreprise, c’est aussi parce qu’ils ont contribué à leur formalisation et que leur cartographie technique s’appuie sur une cartographie métier. Ils sont donc les médiateurs du SI vis à vis des utilisateurs et prennent en charge l’adéquation de l’utilisation des technologies aux besoins des utilisateurs.

Architecte fonctionnel

L’architecte fonctionnel (ou urbaniste du système d’information) est le plus proche de la maîtrise d’ouvrage, bien qu’il tire de nombreux avantages à se positionner au sein de la DSI dans la cellule architecture. C’est un homme de communication qui connaît particulièrement bien le métier et la stratégie de l’entreprise et qui sait mettre en relation les besoins fonctionnels et l’évolution des technologies. C’est sur lui que repose la vision à long terme du système d’information, la cohérence des choix dans le temps. C’est donc le maître de la cartographie particulièrement sur la couche métiers et la couche fonctionnelle.

Son analyse des besoins des utilisateurs, et sa présence constante auprès des directions fonctionnelles doit lui permettre d’évaluer régulièrement la satisfaction des utilisateurs vis à vis du parc applicatif afin d’anticiper les demandes d’évolutions ou de refonte. Il peut ainsi fixer les priorités entre les différentes directions mais aussi permettre la formulation des besoins transverses impliquant plusieurs maîtrises d’ouvrages. Enfin sa maîtrise des processus de l’entreprise lui permet d’identifier tous les impacts d’un projet et de prendre les dispositions nécessaires pour les prévenir.

La capacité relationnelle de l’urbaniste est la compétence primordiale. Ensuite il doit faire preuve de pédagogie pour diffuser et expliquer le plan d’urbanisme du système d’information, aussi bien au sein de la maîtrise d’œuvre que des maîtrises d’ouvrages. Pour cela, il doit s’appuyer sur une très bonne connaissance des métiers des utilisateurs. La modélisation est pour lui un outil du quotidien, il doit donc maîtriser UML.

Architecte applicatif

L’architecte applicatif est le plus généraliste des architectes. Son domaine de prédilection est généralement celui des communications inter-applicatives et de l’intégration des applications entre elles pour répondre aux besoins fonctionnels. C’est donc lui qui traite par exemple de tous les flux de données entre un site web et le système d’information. Il intervient aussi dans le cadre du choix des nouveaux outils sur la dimension de l’interopérabilité afin de garantir une communication aisée avec l’existant.

Enfin, il ne se contente pas de réfléchir à l’utilisation des protocoles, mais s’intéresse aussi aux contenus des échanges et donc aux différents modèles de données des objets métiers de l’entreprise. Ainsi les MCD Merise, les IDOC de SAP et le mapping objet-relationnel sont pour lui des concepts familiers même si les développeurs sont beaucoup plus experts dans l’implémentation.

L’architecte applicatif dispose d’une bonne maîtrise des NTIC (web, mail), des serveurs d’applications, des protocoles et des outils d’intéropérabilité (DCOM, RMI, Corba, Web Services, middlewares et EAI) et des bases technologiques des ERP.

Architecte Réseau

L’architecte réseau est beaucoup plus spécialisé. Son occupation principale est le transport des données, activité qui se mesure en termes de volume, de disponibilité et de qualité de service. Toutes les communications l’intéressent moins pour leur contenu (SGBD, web, mail) que pour leur volume et particulièrement pour leur capacité à générer des pointes de trafic (burst). Ainsi la ruée simultanée de tous les utilisateurs sur leur e-mail dès leur arrivée au bureau est pour lui une source de préoccupation quotidienne. En effet la concentration du trafic autour d’un seul serveur (le serveur de mail) dans une durée limitée peut amener aux limites de l’infrastructure, ce qui provoque sans faillir des commentaires désagréables sur « le réseau qui rame ».

Au delà de ces angoisses quotidiennes, l’architecte réseau planifie les évolutions de l’infrastructure en fonction des statistiques d’utilisation mais aussi en fonction des plannings prévisionnels de déploiement des applications dont il discute avec ses collègues architectes. Lui aussi s’appuie pour cela sur une cartographie qui leur est commune.

Enfin, la sécurité du réseau repose entre ses mains et lui impose de consacrer de nombreuses heures à cette activité aussi discrète qu’ingrate car rarement connue des utilisateurs. Du cadre bricoleur au surfer imprudent en passant par l’employé réellement malintentionné ou tout simplement trop curieux, l’architecte réseau doit prévoir toutes les catastrophes virales ou tentatives d’intrusion que ces importuns pourraient provoquer et prévoir en conséquence les dispositifs de protection ad hoc.

Les compétences dans lesquelles l’architecte réseau excelle sont donc TCP/IP, Token Ring, Frame Relay, X25, le DNS, BGP, DHCP, SMTP, les routeurs et les firewalls.

Architecte logiciel

L’architecte logiciel (ou software designer) est un spécialiste du développement. Son expertise en modélisation fait de lui le concepteur idéal pour toutes les applications spécifiques, mais sa connaissance de l’existant du SI le pousse à réutiliser plutôt qu’à redévelopper. Avec l’architecte applicatif, ils s’interrogent souvent sur le positionnement des référentiels et sur les interfaces qui permettent des les alimenter. Sur la base de ces réflexions, l’architecte logiciel conçoit un composant logiciel réutilisable ou un service logiciel qui sont mis à disposition de toutes les applications qui traitent des mêmes objets métiers. La cartographie applicative est pour lui la source des décisions entre développement et réutilisation et il devrait préférer les progiciels pour les applications non spécifiques. Cependant, les applications spécifiques restent l’espace d’expression de sa créativité, bien qu’il garde à l’esprit le fait qu’elles doivent s’intégrer à l’existant. Ainsi, il accepte d’exposer ses composants sous la forme de messages-driven beans ou de web services afin d’alimenter d’autres applications ou référentiels.

L’architecte logiciel est presque le plus proche des utilisateurs puisque ses développements rendent compte de façon exacte du fonctionnement des processus de l’entreprise. Il est donc celui qui réalise la cartographie la plus proche du métier en s’appuyant sur les descriptions de la maîtrise d’ouvrage.

L’architecte logiciel maîtrise les langages objets, la modélisation, UML, les serveurs d’applications et composants, les architectures logicielles distribuées et l’utilisation des middlewares.

« Chacun sa place et les objectifs métiers seront bien gardés »

Alors que l’architecte logiciel représente le département des études et que l’architecte réseau représente le département de l’exploitation, l’architecte applicatif et l’architecte fonctionnel doivent eux se sentir plus proches des besoins de la maîtrise d’ouvrage.

Ils sont donc les gardiens des objectifs métiers dans la mise en œuvre du SI. C’est pourquoi, fonctionnant dans une vision à moyen et long terme, en dehors des pressions du « mode projet », ils doivent se retrouver régulièrement au sein de la « cellule architecture » pour décider ensemble des orientations, méthodes et bonnes pratiques qui constituent le savoir-faire propre à chaque système d’information.
Au delà des matériels, logiciels, traitements et données, c’est ce savoir-faire qui constitue l’essentiel de l’efficacité du système d’information au service des objectifs métiers (ou business) de l’entreprise.