L’architecture d’entreprise (EA) est une activité aussi difficile que passionnante. C’est une activité pluridisciplinaire puisqu’elle requiert la maîtrise des enjeux économiques de l’entreprise, la bonne compréhension du contexte des métiers, un « savoir faire » emprunté au monde de l’ingénierie, mêlant la rigueur et le formalisme de la modélisation et des représentations abstraites, un « faire savoir » indispensable pour une restitution claire, constructive et pédagogique des enjeux, des représentations ou encore des propositions d’amélioration , enfin un « savoir être » liant passion, reconnaissance des équipes, écoute et disponibilité.
L’architecture d’entreprise s’est imposée à moi quand j’ai commencé à m’intéresser en 2004 au développement durable, notamment à la lecture d’une des œuvres de Georgescu Roegen intitulée « la décroissance ». Georgescu Roegen évoquait déjà dans le milieu des années 70, l’entropie des systèmes.
- « l’entropie peut être interprétée comme la mesure du degré de désordre d'un système au niveau microscopique. Plus l'entropie du système est élevée, moins ses éléments sont ordonnés, liés entre eux, capables de produire des effets mécaniques, et plus grande est la part de l'énergie inutilisée pour l'obtention d'un travail… »
Aujourd’hui d’actualité, avec la crise économique et la chasse au gaspillage, les futures enjeux des urbanistes pourraient bien vouloir répondre à la question « Comment garantir le développement durable des SI des entreprises et d’éviter de transmettre aux générations suivantes le fardeau d’un passif devenu trop pesant, au risque de compromettre leur propre développement. C’est en tout cas, à cette question, que veut répondre la nouvelle méthode PRAXEME de Dominique VAUQUIER.
Concrètement, et au-delà des méthodologies, mon expérience m’a amené à considérer qu’une partie seulement du SI pouvait être formalisé, mais que cette partie était majoritaire, ou destinée à l’être. Comparons alors cette partie formelle à un hyper espace représenté par un modèle, un gros cube, en somme. Les diagrammes, sont des projections de cet hyper cube sur une de ses faces, permettant d’expliquer et de comprendre un point de vue. Les diagrammes d’architecture mettent en lumière des points de vue. Ces points de vue illustrent les parties saillantes et/ou « délicates » d’un Système. Ils sont fabriqués et ordonnés selon les bonnes pratiques, les plans qualités, les principes généraux d’architecture afin de permettre à une organisation humaine de produire de la valeur ajoutée « informatisée », ou plus modestement décrire le système présent et/ou sa projection dans le futur (5 ans max) .
On ne gère pas de la même façon, un processus manuel, et un processus automatisé. Les enjeux dans le premier cas, sont la recherche de l’efficacité, et dans le second cas, la recherche de l’efficience. Entre les deux, c'est la "loi de l'exponentiel" qui fait la différence? Et cette loi peut jouer avec ou contre nous...
28 mai 2010
la DSI en equation
L’équation économique, chère aux Directions du SI, est la suivante, Elle se base en partie, sur le triptyque suivant:
- D'une part, l’existant patrimonial de l’entreprise, en terme d’application informatique que l’on nomme Système informatique. Celui-ci peut, au fil des ans devenir lourd, structurant, et hétérogène. C’est le domaine des solutions informatiques en production.
- l’état de l’art de la technologie, qui promet des gains de productivité, fondés ou non, mais dont la prise en compte est indispensable. L’arbitrage se pose en ces termes : j’attend demain car ça coûtera moins cher et ce sera mieux, mais au risque de vieillir plus vite que la concurrence, ou alors, j’investie maintenant pour continuer une activité performante, avec le risque d’une obsolescence prématurée.
- Enfin les objectifs de la direction générale qui doit se donner les moyens de sa stratégie de développement, en s’assurant que les fonctions métiers du Système d’information seront en mesure de produire de la valeur ajoutée. C'est-à-dire que leurs besoins doivent être couverts par des solutions techniques, de manière efficiente. Les processus métiers doivent être optimisés, pour produire « plus avec moins », en supprimant toute forme de gaspillage.
Le gaspillage en informatique, rime bien souvent avec la notion de redondance et de cycle mal maîtrisé…
- D'une part, l’existant patrimonial de l’entreprise, en terme d’application informatique que l’on nomme Système informatique. Celui-ci peut, au fil des ans devenir lourd, structurant, et hétérogène. C’est le domaine des solutions informatiques en production.
- l’état de l’art de la technologie, qui promet des gains de productivité, fondés ou non, mais dont la prise en compte est indispensable. L’arbitrage se pose en ces termes : j’attend demain car ça coûtera moins cher et ce sera mieux, mais au risque de vieillir plus vite que la concurrence, ou alors, j’investie maintenant pour continuer une activité performante, avec le risque d’une obsolescence prématurée.
- Enfin les objectifs de la direction générale qui doit se donner les moyens de sa stratégie de développement, en s’assurant que les fonctions métiers du Système d’information seront en mesure de produire de la valeur ajoutée. C'est-à-dire que leurs besoins doivent être couverts par des solutions techniques, de manière efficiente. Les processus métiers doivent être optimisés, pour produire « plus avec moins », en supprimant toute forme de gaspillage.
Le gaspillage en informatique, rime bien souvent avec la notion de redondance et de cycle mal maîtrisé…
30 mars 2010
Mes 7 principes pour une EA gagnante
L'Architecture d'Entreprise (EA) connaît un regain d’intérêt (merci la crise) auprès des décideurs de différentes directions, qui dessinent leurs stratégies à trois ans, auprès des économistes qui étudient les perspectives conjoncturelles, et auprès de nous les architectes et urbanistes d’entreprise, en charge de mettre en résonance, le SI et son IT.
Nous définissons l’EA comme un ensemble de bonnes pratiques de modélisation, facilitant, la mise en œuvre des moyens de production, polarisés dans le même sens : celui des objectifs stratégiques et leurs déclinaisons opérationnelles. Retenons que notre organisation ainsi polarisée, offre une propension positive à la création de valeur. Distinguons 2 masses majeures :
1°) Les architectes d’entreprise doivent s’impliquer d’avantage dans la compréhension du contexte métier et s’engager ainsi que leurs collègues "métiers" dans la définition de l’architecture métier. L’EA concerne tous les acteurs de l’entreprise.
2°) Les architectes d’entreprise doivent sensibiliser et éduquer la partie métier. Celle-ci, d’ailleurs, selon mon expérience, n’attend que ça. Mais elle attend aussi de nous de la clarté de notre part, et une compréhension de leur préoccupation. Il est primordial que les organisations développent et utilisent un plan de communication sur l’architecture d’entreprise avec des messages spécifiques et ciblés.
3°) Les architectes séniors d’entreprise doivent être des managers. En plus de leur « savoir faire » reconnu, leur « savoir être » doit l’être tout autant. L’enthousiasme, la passion, l’engagement, le respect de leurs équipes, de leurs pairs, et leur gout pour la stratégie, en font des acteurs incontournables. Fédérer, éduquer et sensibiliser, sont les trois mamelles de la communication de l’architecte Manager, pour assurer la polarisation des équipes (et pas seulement celle de l’IT).
Selon le Gartner, L’essentiel est de « vendre d’abord » puis « de faire de l’architecture ensuite »
4°) Les architectes d’entreprise doivent rechercher l’adhésion des "équipes transverses" pour créer le contenu et rechercher le consensus sur le contenu. Les livrables IT sont hors sujet en l’absence d’une accréditation métier, et sans accréditation métier, il n’y a pas d’adhésion de l’entreprise pour l’architecture d’entreprise. Qui est le sponsor ? Qui légitime(nt)/ encourage(nt) notre démarche ? Qui décident vraiment ?
5°) Les architectes d’entreprise doivent établir le contexte métier et démarrer par la cible. En effet, la tentation de commencer par les processus métiers les plus simples, est grande. La prise en compte d’éléments de valeur par l’architecture d’entreprise est alors retardée et ce retard entrave la création de valeur. Tiens tiens, on retrouve ici, nos bon vieux principes SOA de recherche de critères des processus à urbaniser en premier...
6°) Les architectes d’entreprise doivent aussi faire leur pub. La valeur de l’EA n’est pas perçue immédiatement, ni perçu par tous les acteurs de l’entreprise. Cela met en péril la démarche et aboutissement positif de cette démarche. Informer, « buzzer », exprimer factuellement, les succès établis de l’EA, et les enjeux immédiatement à venir notamment sur les projets. S’appuyer sur des éléments factuels, mesurés et établis n’est pas très difficile, avec un peu d’imagination économiques.
7°) Les architectes d’entreprise doivent proposer plus d’agilité et cesser de brider les corps d’élite du métier, par des règles d’un autre temps. Nous affirmons ici trois prises directes avec le SI pour apporter une réelle agilité de fait. Agir simultanément sur :
- la maitrise des Processus métier, ou comment faire travailler les acteurs ensemble.
- la gestion des données maîtres (voir processus opérationnels)
- la maitrise des règles métiers, et leur déploiement massivement contrôlé.
(Ce dernier point ne fait pas l’unanimité, et cela est bien dommage. Mon expérience sur l’utilisation des moteurs de règles, m’a prouvé, son efficacité. Comment être le meilleur et surtout le rester…)
Emmanuel PESENTI, Architecte Senior chez Softeam Consulting
Nous définissons l’EA comme un ensemble de bonnes pratiques de modélisation, facilitant, la mise en œuvre des moyens de production, polarisés dans le même sens : celui des objectifs stratégiques et leurs déclinaisons opérationnelles. Retenons que notre organisation ainsi polarisée, offre une propension positive à la création de valeur. Distinguons 2 masses majeures :
- L’entreprise et son SI, porteuse d’une vision, et de besoins, pour sa marche en avant.
- L’entreprise et son IT, porteuse de solution, d’innovation technologique, de formalisme, et parfois aussi de limites.
1°) Les architectes d’entreprise doivent s’impliquer d’avantage dans la compréhension du contexte métier et s’engager ainsi que leurs collègues "métiers" dans la définition de l’architecture métier. L’EA concerne tous les acteurs de l’entreprise.
2°) Les architectes d’entreprise doivent sensibiliser et éduquer la partie métier. Celle-ci, d’ailleurs, selon mon expérience, n’attend que ça. Mais elle attend aussi de nous de la clarté de notre part, et une compréhension de leur préoccupation. Il est primordial que les organisations développent et utilisent un plan de communication sur l’architecture d’entreprise avec des messages spécifiques et ciblés.
3°) Les architectes séniors d’entreprise doivent être des managers. En plus de leur « savoir faire » reconnu, leur « savoir être » doit l’être tout autant. L’enthousiasme, la passion, l’engagement, le respect de leurs équipes, de leurs pairs, et leur gout pour la stratégie, en font des acteurs incontournables. Fédérer, éduquer et sensibiliser, sont les trois mamelles de la communication de l’architecte Manager, pour assurer la polarisation des équipes (et pas seulement celle de l’IT).
Selon le Gartner, L’essentiel est de « vendre d’abord » puis « de faire de l’architecture ensuite »
4°) Les architectes d’entreprise doivent rechercher l’adhésion des "équipes transverses" pour créer le contenu et rechercher le consensus sur le contenu. Les livrables IT sont hors sujet en l’absence d’une accréditation métier, et sans accréditation métier, il n’y a pas d’adhésion de l’entreprise pour l’architecture d’entreprise. Qui est le sponsor ? Qui légitime(nt)/ encourage(nt) notre démarche ? Qui décident vraiment ?
5°) Les architectes d’entreprise doivent établir le contexte métier et démarrer par la cible. En effet, la tentation de commencer par les processus métiers les plus simples, est grande. La prise en compte d’éléments de valeur par l’architecture d’entreprise est alors retardée et ce retard entrave la création de valeur. Tiens tiens, on retrouve ici, nos bon vieux principes SOA de recherche de critères des processus à urbaniser en premier...
6°) Les architectes d’entreprise doivent aussi faire leur pub. La valeur de l’EA n’est pas perçue immédiatement, ni perçu par tous les acteurs de l’entreprise. Cela met en péril la démarche et aboutissement positif de cette démarche. Informer, « buzzer », exprimer factuellement, les succès établis de l’EA, et les enjeux immédiatement à venir notamment sur les projets. S’appuyer sur des éléments factuels, mesurés et établis n’est pas très difficile, avec un peu d’imagination économiques.
7°) Les architectes d’entreprise doivent proposer plus d’agilité et cesser de brider les corps d’élite du métier, par des règles d’un autre temps. Nous affirmons ici trois prises directes avec le SI pour apporter une réelle agilité de fait. Agir simultanément sur :
- la maitrise des Processus métier, ou comment faire travailler les acteurs ensemble.
- la gestion des données maîtres (voir processus opérationnels)
- la maitrise des règles métiers, et leur déploiement massivement contrôlé.
(Ce dernier point ne fait pas l’unanimité, et cela est bien dommage. Mon expérience sur l’utilisation des moteurs de règles, m’a prouvé, son efficacité. Comment être le meilleur et surtout le rester…)
Emmanuel PESENTI, Architecte Senior chez Softeam Consulting
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.
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.
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.
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
- 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)
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
Inscription à :
Articles (Atom)