02 février 2010

Mission de formation en Algérie

Je reviens d’une mission de un mois dans le cadre d’un plan de formation générale, dispensé à de jeunes ingénieurs algériens fraichement diplômés, de l’université d’ANNABA. L’objectif de notre client est d’amener progressivement ses nouvelles recrues à un niveau de qualité « à la française ». Le plan s’est déroulé sur 3 mois, durant lesquels, nous avons déroulé un cursus très complet de formation, allant des aspects de modélisations et de conceptualisation, jusqu'au développement et l'implémentation de solutions objet (JEE, C#).
En tant qu'architecte sénior chez Softeam, j'ai participé à la réponse commerciale et assumé la responsabilité des cours de modélisation UML, méthodes phases amont, et mapping relationnel objet, sur une durée de 1 mois. Autant dire que le programme était très dense.

Notre client, M. Yazid B. est Docteur Ingénieur diplômé de SUPAERO (1985), titulaire d’un DEA en Génie Logiciel, et membre de l’Académie de l’IE. Il assure aujourd’hui la Présidence et la Direction Générale d’une SSII spécialisée dans la réalisation de travaux informatiques offshore (externalisés) en Algérie : CAS2I. Je salue M. Yazid B. au passage, en le remerciant encore de son accueil. "Il y a des hommes, au contact desquels, on apprend"...

Nos amis algériens nous ont très bien reçus, et même si le niveau global est en deçà des standards, la motivation et le courage font la différence. « La volonté de réussir ne fait qu’ajouter à la nécessité d’entreprendre » disait M. de Beaumarchais. Qu’à cela ne tienne, le témoignage que je vous ramène d’Algérie, est des plus prometteurs. Ces jeunes ingénieurs algériens m’ont donné l’image de personnes, motivées, courageuses, mais aussi souriantes, et tolérantes, loin des clichés qui, parfois, occupent nos ondes. Bien sur, tout n’est pas rose, et certaines uses et coutumes peuvent parfois bousculer nos principes occidentaux, (et la réciproque est vraie).
Ce pays va se reconstruire après 10 ans de crises… et les échanges succèderont à une confiance mutuelle retrouvée, du moins souhaitons-le...

Je tiens à remercier, mes trois compères avec qui j'ai oeuvré 1 mois durant:
- M. Jean S., Formateur C#, grandement reconnu pour ses compétences et ses valeurs humaines.
- M. Pierre Olivier H., Formateur JEE, dont je salue la conscience professionnelle, et l'engagement.
- M. Bernard L., Formateur JEE, également bien apprécié les stagiaires, et auteur du cas d'étude "Fermland".

Je tiens aussi à remercier, ces trentes jeunes ingénieurs qui nous ont accueilli et en particulier,
D. Mehdi, M. Said , S.Mohamed Anis , AMIR D., H. Faycel, D. Faiz Naim, pour leur bonne maitrise de la langue française.

Souhaitons leur, bon vent et toute la réussite qu’il mérite, au sein de CAS2I.

C’est quoi un Architecte ?

Dans le monde des systèmes d’information (SI), le terme « Architecte » suscite souvent la confusion, voire même l’incompréhension. Son rôle et ses attributions sont confus. Cela provient certainement du fait qu’il faudrait en réalité distinguer quelques spécialités et donc faire suivre le terme « architecte » d’un qualificatif plus précis.
  • Architecte Fonctionnel (connu aussi sous le terme d’urbaniste ou d’architecte d’entreprise)
  • Architecte Applicatif (côté communication, protocole, données et interopérabilité)
  • Architecte Réseaux (côté sécurité, volume, flux, temps de réponse)
  • Architecte Logiciel (côté conception, Framework, et code)
Bien que leurs attributions au sein du SI, soient différentes, ils partagent un certain nombre d’objectifs. Ce sont des hommes d’ensemble et de durée, garants de la cohérence et de la pérennité du SI. Nous faisons la distinction entre système d’information (SI) et système informatique. Ce dernier étant strictement inclus dans le SI, et couvrant la totalité des solutions dites informatisées. Les architectes réseaux et logiciel sont clairement au service du système informatique, et donc indirectement servent la cohérence et de la pérennité du SI. L’architecte applicatif garantira dans le temps des solutions ou plutôt des briques de solution conforme au plan d’urbanisme, en respect de certains standard choisis, avec une vision « boite blanche » sur chacune des briques, afin de les optimiser. Enfin l’architecte fonctionnel fait le pont entre les projets et la durabilité indispensable du SI. Il est au service des stratèges de l’entreprise, et responsable du plan d’urbanisme, du respect des objectifs…
LE RÔLE DES ARCHITECTES
Au travers de leurs attributions, on voit bien 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, les besoins des utilisateurs et la viabilité économique des opportunités. Cette capacité d’anticipation et leur positionnement transverse auprès des chefs de projets, des maîtrises d’ouvrage et des exploitants, leur permet de faire respecter les grandes lignes stratégiques de la DSI.
Cependant ces compétences de technologues ne doivent pas masquer l’importance du lien qu’ils maintiennent entre fonctionnel et technique.
Les échanges et les confrontations « logiques techniques » telles que décrites, notamment dans PRAXEME, sont une caractéristique fondamentale, impliquant les piliers de l’architecture du SI.

  • Ils savent expliquer comment sont implémentés les processus métiers de l’entreprise.
  • Leur cartographie technique s’appuie sur une cartographie métier.
  • Ils sont donc les médiateurs du SI vis à vis des utilisateurs et de l’adéquation technologiques.

Architecte fonctionnel

L’architecte fonctionnel (ou architecte d’entreprise) est le plus proche de la maîtrise d’ouvrage. Il tire cependant, 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. Il est le maître de la cartographie particulièrement sur la couche métiers et la couche fonctionnelle, et le passage obligé pour tout changement impactant le SI.
Son analyse des besoins utilisateurs, et sa présence constante auprès des directions fonctionnelles lui permettent 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 doit 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 sa compétence primordiale. Il doit aussi faire preuve de pédagogie pour diffuser et expliquer le plan d’urbanisme du SI, aussi bien au sein de la MOE que des différentes MOA. 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 et autres modèles de classe, les IDOC SAP et le mapping relationnel-objet sont pour lui des concepts familiers même si les développeurs sont plus experts que lui 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’interopé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. 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, ce qui provoque des commentaires désagréables comme : « le réseau 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 de 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 en pratique, 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. Il 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.

voir aussi
: http://www.clever-age.com/veille/clever-link/mieux-definir-les-metiers-d-architectes.html