Traditionnellement, la direction des systèmes d’information comprenait deux grands pôles, les études et la production. Au fil du temps, elle a été éclatée en un nombre d’équipes plus important : les architectes, la sécurité, l’interface avec la ma”trise d’ouvrage, les projets, les processus métier, etc. Enfin, avec le développement par composants, toutes ces activités tendent à se recentrer autour d’un pôle unique, celui de l’architecte.
En effet, la fonction d’intégrateur, désormais responsable de l’architecture technique d’assemblage des composants, voit son rôle se confondre avec celui de l’architecte. Et le travail de ce dernier s’effectue en collaboration avec toutes les équipes. “L’aspect architectural est primordial, insiste Philippe Desfray, directeur général recherche et développement de Softeam. L’architecte peut être le chef de projet. Mais il détermine aussi la façon de développer les composants en fonction de la technologie utilisée : Corba, DCOM ou EJB. Il définit également comment un composant est réparti entre les différentes couches.” En bref, son rôle est multiple et complexe. Il est non seulement chargé de concevoir et de construire l’infrastructure informatique, mais aussi de la valider, d’évangéliser et d’apporter un support aux développeurs.
Le choix fait par l’architecte a une incidence sur toute l’entreprise
Le travail d’architecte proprement dit consiste à déterminer comment décomposer une application ou une famille d’applications en un système à base de composants. Pour cela, il définit les besoins actuels et identifie les composants communs afin d’éviter les doublons. Mais il anticipe aussi sur les besoins futurs. Une fois tous les besoins définis, il développe une architecture. Il choisit aussi les différents composants à réutiliser ou à développer, en amont du projet. Il préconise l’utilisation de modèles (patterns) orientés objet pour les différentes phases : analyse, conception et implémentation. Il propose des ” frameworks “, ou squelettes d’architecture, qui accéléreront le développement. Ceux-ci permettent de définir la structure globale, les collaborations entre les classes, les objets et les tâches de contrôle d’une application pour le domaine concerné. Il lui faut aussi prendre en compte la performance, l’adaptabilité et l’évolutivité afin que l’architecture ainsi conçue constitue un ensemble facile à prendre en main par les développeurs.
Mais, en général, le choix de l’architecture affecte toute l’entreprise, et non un seul projet. L’architecte doit donc bâtir une stratégie en s’appuyant sur une infrastructure commune à tous les développements de l’entreprise. Une responsabilité d’autant plus lourde que les composants disponibles ” sur étagère ” ne sont généralement utilisables que sur une seule infrastructure (Microsoft, Java-EJB ou propriétaire). De plus, s’il peut décider pour sa propre entreprise, l’architecte n’a que rarement le pouvoir d’imposer ses choix aux partenaires de la firme. Il sera donc obligé de passer par des passerelles, notamment basées sur XML pour l’échange de données et d’informations. Cette tâche peut être assurée par une personne à part entière ou par une équipe.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
