Comment intégrer des Progiciels dans une architecture d’entreprise ?

Le CEISAR organise une présentation sur ce thème, le mardi 14 juin à 18 heures dans les locaux du groupe AXA : 25 avenue Matignon, 75008 PARIS.

Le livre blanc, sera dévoilé à cette occasion...
Si vous souhaitez participer à cet évènement, n'hésitez pas à vous inscrire à l'adresse :

contact@ceisar.org

 à l'attention de M.

Pierre-Frédéric Rouberties
Center of Excellence in EnterprISe ARchitecture
Ecole Centrale Paris
www.ceisar.org


Extrait du livre blanc qui sera diffuser, à cette occasion
Les Entreprises font de plus en plus appel à des Progiciels, non seulement pour des besoins de Commodité, mais aussi pour des besoins Verticaux propres à leur secteur d’activité. Mais un assemblage de Progiciels indépendants pose des problèmes considérables de coexistence : duplication d’informations, usage hétérogène, synchronisation des évolutions de chacun, ressaisies d’information, difficultés à monter des offres mixtes…
- Quelles sont les recommandations qui peuvent être faites pour aboutir à une architecture de progiciels harmonieuse ?
- Que rôle le Cloud peut-il jouer ?
- Quelles sont les bonnes pratiques pour mettre en œuvre un Progiciel ?
- Quelles précautions doit-on prendre pour les versions successives du progiciel ?
- Comment réduire les couts d’installation de progiciel ?
- Comment faire évoluer le progiciel une fois qu’il est en place ?
....

Le CEISAR remercie tout particulièrement les acteurs suivants Pour leur contribution active à la fabrication de ce livre blanc :

• Afdel : Loïc Rivière et Stéphanie Jullien
• Air France : Laurent Mondemé, Francis Bailly
• Amadeus : Stéphane Tabary
• Axa : Hervé le Hen, Luc Morin
• Cegid : Florence Desprets, Jean-Louis Decosse
• Club des Pilotes de Processus : Didier Lejeal, Henri Chelli, Henri-Paul Soulodre, Pierre Dautet, Michel Verdun
• Conseils-Plus : Pierre Hugot
• ITN : Alain Dubois
• Logica : Emmanuel Pesenti
• Oracle : Didier Medal
• OR System : Anis Bada
• Renault (RCI Banque): Olivier Chagnou
• SAP : Thierry Pierre
• SFEIR : Didier Girard
• Stallergènes : Jean-Pierre Bouillaguet, Jacques Lelièvre
• Total : Bruno Bosquette
• W4 : François Bonnet
• Weave : Julien Soyer
• Wyde : Laurent Pytel

Système Informatique ou Système d’Information ?

Je discutais, samedi dernier, avec une personne de mes connaissances, « Project Manager Officer » de son état. Nous accompagnions nos enfants au conservatoire, pour la leçon de violon hebdomadaire. La discussion s’engage sur une de nos préoccupations communes du moment : Le projet X à quelques 4 milliard d’€ et des brouettes.
Au bout de 5 minutes, je demande à mon interlocuteur : - « Mais que signifie cet acronyme S.I. prononcé depuis le début, à plusieurs reprises ? La réponse quasi-automatique fut « Système d’Information, voyons » est pourtant, les mots employés dans un contexte non technique était: Machines, Serveurs, Protocole, Agents intelligents, Logiciels embarqués, allant jusqu’à une esquisse de mise en œuvre… Génial, … Oui mais … De quoi parle-t-on ? Système Informatique ou Système d’Information ?

Au risque d’enfoncer des portes ouvertes, Mes pairs urbanistes et autres architectes d’entreprise me pardonneront de me livrer, ici, à un exercice de pédagogie sur notre profession et les moyens, utilisés. N’est-ce pas là d’ailleurs, la véritable vocation de ce blog ?

Nous parlons probablement des deux, mais avec une imprécision flagrante liées au contexte, au projet, et aux limites des postures de chacun. L’architecte d’entreprise (appelé encore Urbaniste, ou Architecte fonctionnel) est au Système d’Information ce que les architectes techniques, les architectes applicatifs, et autre super architectes logiciels, sont au Système Informatique. C’est là, une première différence palpable entre les deux systèmes.

L’I.T. (Système informatique) est l’ensemble des actifs matériels et logiciels de l’entreprise ayant pour vocation à automatiser le traitement de l’information. C’est la partie visible à laquelle tout le monde pense quand on parle de projets et d’infrastructures informatiques. On y inscrit également la R&D, l’innovation technique, et toutes les techniques d’optimisation. Pour résumer, le logiciel, le serveur qui va bien et les écrans...

Le S.I. (Système d’information) est l’ensemble des actifs de l’I.T. (matériels et logiciels, forcement référencé quelque part) mais comprend aussi et surtout, les actifs humains et immatériels, les procédés, procédures, et processus, d’industrialisation, sur lesquels on les affecte, les informations de niveau sémantique, organisationnelle, et de structure, dites « Amont ».

Question : À quelle famille d’actif, peut-on associer la flotte de véhicule bleue d’EDF ?
La réponse est très simple, au premier abord, mais mérite d’être nuancée. Elle n’intervient à priori pas dans l’automatisation de tel ou tel service déployé, Son usage est manuel, et elle n'interagit à priori qu'avec son chauffeur ; donc on peut facilement comprendre que l’actif en question ne sera pas manager par une direction informatique. Est-ce pour autant un actif du Système d’Information ?

Analysons :
- Existe-t-il un ou plusieurs documents référençant ma camionnette bleue ?
- Ces documents montrent-ils une interaction avec un acteur identifié de l’organisation ?
- Peut-on trouver un premier niveau de formalisme d’un procédé ou mieux d’un processus d’entreprise intégrant ma camionnette bleue et son chauffeur ?
Une réponse négative à ces questions et fin de l’histoire : le véhicule est réduit à un actif comptable à amortir, et c’est sa seule existence dans le S.I.
Une réponse positive à ces questions permettrait d’induire que la camionnette est bien une ressource saillante dans le Système d’Information, en plus du système comptable, et contribue, dans une ou plusieurs tâches identifiées, à produire de la valeur.
- Puis au détour d’un autre processus métiers lui, parfaitement modélisé, on se rend compte, qu’un message entrant fait acte du nom du chauffeur, de la plaque d’immatriculation du véhicule, de la durée d’intervention et du kilométrage. Tiens Tiens, Ma fameuse camionnette bleue serait elle un objet métier, prompt à faciliter ma compréhension des processus et de leur interaction et/ou à automatiser un système futur ?
- Puis la direction générale, dans un communiqué historique, affirme son intention de réduire les coûts d’intervention, en prévoyant mieux les révisions ateliers des véhicules bleus. Là le faisceau d’information permet clairement de le considérer comme un objet métier, et donc un actif du SI, qui risque de prendre de plus en plus d’importance dans les processus à venir.

- 10 ans plus tard, le petit véhicule bleu, n’est plus bleu. Il n’a plus de chauffeur, il est truffé de logiciels dont une partie est stratégiquement développée en interne, et l’autre par un prestataire prestigieux. Il interagit en temps réel avec une base centrale de données, à l’aide d’un protocole non connu 10 ans plus tôt. Sa promotion dans plusieurs processus métiers, a été un facteur concurrentiel de développement déterminant, permettant de rendre l’activité non seulement durable dans le temps, mais rentable. Et oui, L’architecte d’entreprise est un homo économicus, du développement durable…
- Le suivi et la modélisation du SI a permis 5 ans auparavant, de faire une fusion acquisition gagnante avec cette société si brillante dans le développement de logiciels embarqué, comblant le vide fonctionnel que l’architecte d’entreprise avait détecté suite aux intentions de la DG.
- La DG (qui n’est pas frileuse) avait anticipée cela 10 ans plus tôt avec l’aide de son architecte d’entreprise.
- Les moyens utilisés pour « bâtir »sont tout simplement « la modélisation ». Cette discipline, empruntée à l’ingénierie des systèmes, et aux techniques de modélisation « objet » permet d’allier formalisme et rigueur, dans les différentes projections, transformation, et dérivation de modèle opéré pour bâtir un ouvrage stable dans le temps. Les procédés et les réflexes de modélisation sémantique, par exemple, sont sensiblement, les mêmes que ceux de la modélisation des données : Ce sont les objets eux-mêmes, qui diffèrent, ainsi que leurs dépendances. Si l’on comprend la différence entre Mathématiques et Physique appliquée, Alors par transposition respectivement sur SI et I.T., ou sur Concepts et data, les différences sont semblables…

Conclusions partielles :

- Le S.I. offre un outil, à moyen et long terme, pour se projeter, dans l’avenir, en captant la stratégie de l’entreprise, en la projetant et en la décomposant afin de faciliter l’alignement de solutions économiquement viables et durables.
- L’I.T. est une image fidèle du système informatique opérationnel, actuel, lui-même une réponse concrète et économique, des visions stratégiques précédentes, et dont la responsabilité des managers et de rendre son usage aussi fluide, agile, et utile que possible… et la tâche n’est pas simple.
- Le mode projet devrait intervenir sur une vision à maturité du SI de demain, de façon à permettre la transition. Un projet peut donc être considéré comme une transition entre l’IT d’aujourd’hui et l’IT de demain, avec une date de début, une date de fin et un objectif « SMARTE »
- Tout actif matériel a vocation à abonder le SI. L’adéquation économique et technique en fera peut être un actif de l’I.T. dans la vision stratégique, puis concrétisé dans un projet.
- Il est de plus en plus évident que l’adéquation économique anticipée doit prendre immédiatement en compte la composante énergétique comme la future grosse contrainte qui nous attend ; Le seul problème dans cette affaire, est que « tous les dirigeants aujourd’hui naviguent à vue »

Voici donc exposé, sous forme ludique, la différence fondamentale entre une démarche SI et son pendant I.T. Les frictions qu’il existe parfois entre les deux mondes à vocation plus complémentaire que concurrente, en découlent directement, les uns étant taxé de « philosophe aux théories fumeuses », les autres, de tekkos aux cheveux long et aux idées courtes.
Ma position personnel en tant qu’architecte d’entreprise est la suivante : Le respect et l’écoute des uns et des autres est une composante fondamentale pour agir consensuellement, chacun à sa place :
- Collègues et Amis Architectes, chaque fois que votre interlocuteur, vous dira : « Euh c’est trop technique », il est probable qu’en réalité, il n’ait rien compris à ce que vous lui disiez, et pour garder la tête haute, il botte en touche.
- Collègues et Amis MOA, chaque fois que votre interlocuteur, vous dira : « Euh, Pourquoi vos besoins ressemblent-ils à des spécifications détaillées », c’est que probablement vous ne travaillez pas avec des architectes d’entreprise, challengeant ce qu’il y a de meilleur en vous : La vision d’avenir et la compréhension des métiers. Pas la solution.

Je continue de penser que pour être innovant et riche, l’architecte technique a fondamentalement besoin d’une vision mature et de besoins clairement exprimés, par les urbanistes et les MOA. L’innovation, a besoins de garder son âme d’enfant, car un enfant est détaché des contraintes et des habitudes dont certaines devront être remises à plat. Les architectes d’entreprise, même si là n’est pas leur vocation, savent aussi écrire une requête SQL optimisé, connaissent la différence entre une variable, statique et d’instance, un pointeur et une référence. Ils savent développer dans leur langage favori, mais ils sont plus utiles encore à faire ceci.

BRMS : L'intérêt

Du décideur qui impose au plus 2% de risque pour l’année en cours, ou 15% de pénétration de marché, à l’attaché commercial, qui applique consciencieusement les préconisations d'un processus métier devenu Intelligent, tout le monde est concerné par le Business Rule Management.

Le "Business Rules Management" est le bras armé, le levier "tactique", du décideur qui trouve l'opportunité enfin de naviguer autrement qu'à vue dans son écosystème que la concurrence tisonne.
A partir d'une vision gagnante aussi appelé "Stratégie" le décideur verra son beau discourt suivi au plus prés, par ses équipes opérationnelles, auxquelles il assigne le devoir de résultat et le sens de la marche. La mise en œuvre, donc, de la stratégie d'entreprise, est largement assurée par une solution automatisée de gestion des règles métiers: Le BRMS... Mais comment est-ce possible ?

Comment fait-on pour qu’une décision commerciale, une décision de limitation de risque, ou une décision de crise, soit mise en production et appliquée uniformément sur toute la juridiction concernée (France, Internationale), en seulement 2 jours, test compris ?
On met en place une organisation du type « BRM »

Comment fait-on pour suivre scrupuleusement des objectifs à long terme, énoncés par la DG, et expliqué les écarts, de façon certaine (en moyenne)?
On met en place une organisation du type « BRM»
Appelons cela, de l’agilité opérationnelle, piloté par les lignes métiers.

Chaque fois que l'on peut identifier dans un processus, les caractéristiques suivantes, alors il faut sérieusement regarder de près une solution de type BRMS:

1. Je dispose de beaucoup de règles métier.
2. Elles sont complexes.
3. Elles sont fréquemment modifiées.
   

Leur mise en place, en particulier dans les domaines du crédit, de la finance, de l'assurance, ou des télécom, peut s'envisager sereinement dès lors que :

1. L’organisation opérationnelle sépare distinctement expert métier et cellule technique.
2. La définition des rôles d’expert est claire,
   
3. et la stratification des domaines de règles, est précise,

Alors les conditions seront réunies, pour simplifier la mise en œuvre.


Cela permet d'avoir une démarche durable avec :

1. des gains concurrentiels de développement économiques induits,
2. de l’agilité structurelle pour l’application d’une politique économique (Arbitrage Risque vs gain de part de marché)
3. une organisation spécialisée, capitalisant sur ces règles métiers,
4. la nécessité de les pérenniser au-delà du stockage en matière grise.

BRMS : La troisième dimension

La Gestion automatisée des Règles Métier, (Nos amis anglophones parlent de Business Rules Management Solution) est l'un des axes fort qu’il reste à explorer par les grands acteurs du marché, pour poursuivre l’indispensable quête d’agilité de leur SI. Après le BPM et le MDM place au BRM.

Le BRMS puise fondamentalement ses racines dans la mouvance des Systèmes Experts exploités avec un succès très relatif en France et dans le monde, à partir des années 1995, sur fond d’Intelligence Artificielle. Mais le BRMS, c’est beaucoup plus qu’un moteur d’inférence et ses services techniques (compilation du langage pseudo naturelle en expertise formelle, génération du code de la dite expertise, …) Le BRMS dispose d’un véritable référentiel de connaissances où se greffent une multitude de service transverses profitables aux métiers. De plus, il définit clairement la granularité de réutilisation des règles qui n’existaient pas dans les SE. (Les architectes d’entreprise le savent bien, dans notre métier, tout ou presque, est question de granularité). En outre, le BRMS automatise la chaîne transverse, d’industrialisation des règles entre les acteurs IT et métiers avec une meilleure synergie entre les équipes.

Sur le schéma ci-dessus, on distingue en bleu un macro processus composé de sous processus métier en chaîne. En transverse (marron) on représente les expertises distinctes prompts à paramétrer un processus. Un processus peut disposer de plusieurs expertises possibles. Les règles d’une expertise sont mutualisées au sein d’un référentiel.

Le BRMS simplifie donc, les processus, ré-agence les procédures, aux bénéfices des métiers et des MOA. Sans gouvernance globale de la règle, motivée par des sponsors du métier, les bienfaits d’une gestion automatique à la portée des métiers, ne viendront pas.
Enfin on peut dire que le BRMS est le retour d’une bonne idée. Et que les cabinets de conseils sont en train de prendre en compte, cet ultime axe d’agilité pour peaufiner leur offre actuelle de gouvernance.

Aujourd’hui mon constat sur l’adoption des BRMS est le suivant :
1. Les entreprises françaises qui depuis 15 ans gagnent avec leur SGRM ne sont pas très nombreuses. Quand elles réussissent à mettre en place cette technologie, elles ne s’en vantent pas « Vivons heureux, Vivons cachés » pour ne pas risquer d’attiser la concurrence, sur cette excellente solution. Les Systèmes Experts et autre moteurs à règles de calcul ont été pour ses entreprises, un facteur concurrentiel de développement très important. Elles devraient pouvoir passer au BRMS sans trop de difficultés, d’un point de vue technique. Reste l’optimisation de leur processus métier encore parfois trop teintés de technicités informatiques.
2. La technologie est là. Elle est mure, elle fonctionne très bien, et les éditeurs ont du talent à revendre. Les solutions packagées, proposées sur le marché sont diverses, et se distinguent soit par l’abondance de services intégrés, soit sur des aspects très spécialisés dans le domaine des sciences et de la défense. Tantôt la solution se présente comme une offre globale, et parfois comme un système pointu accompagnant l’expert dans son travail.
3. Les majors du conseil et de la gouvernance des SI, anticipent tous l’explosion des solutions BRMS, dans les 2 à 3 prochaines années.
4. Les entreprises qui ont investi et gagné hier, avec leur système expert propriétaire, sauront-elles rester leader, en regardant entre autre les évolutions considérables que les BRMS modernes apportent par rapport aux moteurs de règles d’hier. (Voir le billet sur la DSI en équation)
5. Par ailleurs, on distingue aussi dans le paysage, des entreprises qui ont essayé et qui ont échoué. Celles-ci ne s’en vantent pas non plus. Elles se contentent d’affirmer à tort : « On a déjà essayé, ça ne marche pas ???

Avant toute chose, il faut tordre le coup à ce type de réponse, qui malheureusement a contribué à faire prendre tant de retard, dans un pays où l’intelligence n’est pourtant pas qu’artificielle. Les deux raisons que j’ai pu constatées pour justifier cet état de fait sont :
- D’une part, la frilosité des décideurs touchés par le syndrome de St Thomas. « On attend de voir pour y croire » Du coup on se contente de demander à l’IT de faire des POC pour « Analyser le potentiel de la solution » Humm Potentiel de quoi et Solution à quel besoins ? C’était mal parti ; Cela ne pouvait pas aboutir. Les acteurs bénéficiaires et contributeurs ont été mal identifiés dès le départ.
- D’autre part, l’offre des éditeurs de solutions, bien qu’excellentes, a eu du mal à trouver son marché. Vendre des licences de logiciel n’est pas suffisant. Cette grande assurance qui a acheté un produit BRMS en pointe, qui est resté au placard, cette autre banque de détails, qui a mis en œuvre une solution BRMS sur un pricer et qui court toujours derrière son ROI, faute de s’être trompé de cible.
Il faut l’accompagnement d’un acteur d’expérience, et neutre, pour comprendre les besoins, les challenger, et améliorer la configuration organisationnelle des métiers, avant de s’engager sur la solution. C’est le rôle des cabinets de conseil. De plus si le BRM est en lisse pour émerger enfin, Cela vient du fait que les efforts se soient d’abord portés sur la cartographie des processus métiers (BPM), et la gestion des données de référence (MDM).

Place désormais aux BRM.
Alors… Ou en êtes vous dans vos règles métiers, et est-ce que ça « Rule » pour vous ?

BRMS : L'ordre d'un Système Expert

En informatique de gestion l'expérience prouve que la grande majorité des problèmes d'aide à la décision peuvent être résolus à l'aide d'un moteur à règles de calcul d'ordre 0+.
Il s'agit d'un très bon compromis permettant d'allier facilité de maintenance, et suffisance du raisonnement.

Mais, que signifie ordre 0+ ?

Commençons par expliquer ce qu'est un SE d'ordre 0.
Les plus simples des systèmes experts s'appuient sur la logique des propositions (dite aussi « logique d'ordre 0 »). Dans cette logique, on n'utilise que des propositions booléennes. Pour des déductions du monde réel, on obtient un système expert très verbeux, et peu paramétrable.
Par exemple, "Age=36 ans" représente un et un seul mot insécable qui est vrai ou faux.
Soit A la proposition : "Le client a 36 ans. Pour exprimer dans un règle d'octroi par exemple, le fait que tous les clients ayant entre 18 et 78 ans, sont éligibles il faudra écrire une règle de quelques 60 clause séparée de OU logiques. Chaque proposition est initialisée à FAUX, et il suffit qu'une des 60 propositions, soit valorisée à VRAI pour que la règle soit VRAIE. Pas très passionnant :-) ...

Les SE d'ordre 0+.
C'est là que l'on appréhende maintenant l'intérêt d'un système logique d'ordre 0+ dans lequel il est possible de paramétrer des propositions logiques. La logique d'ordre 0+ contient des opérateurs de comparaison (>, <, =, >=, <= et <>), des valeurs comparables, des constantes, des énumérations permettant de définir l'ensemble de définition d'une variable.
Ainsi la règle d'octroi précédente devient : SI AGE > 18 ET AGE <=78

Et les SE d'ordre 1.
D'autres systèmes experts s'appuient sur la logique des prédicats du premier ordre (dite aussi « logique d'ordre 1 »). Cette logique fait intervenir des quantificateurs de type "POUT TOUT x" ou encore "QUELQUE SOIT x" x étant une variable prédicative de classe X.
Un raisonnement en logique d'ordre 1 permet de faire des miracles de déduction. Cependant un système expert de 500 règles (de taille moyenne) est difficile à maintenir par la dite population NI INFORMATICIENNE, NI MATHÉMATICIENNE.

En effet en logique d'ordre 1, Gödel démontra en 1931 deux résultats mathématiques :
• Il se peut que dans certains cas, on puisse démontrer une chose et son contraire (théorème d'inconsistance).
• Il existe des vérités mathématiques qu'il est impossible de démontrer (théorème d'incomplétude).

L'Economie des SI

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...

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é…

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. L’entreprise et son SI, porteuse d’une vision, et de besoins, pour sa marche en avant.
2. L’entreprise et son IT, porteuse de solution, d’innovation technologique, de formalisme, et parfois aussi de limites.

Outre les différences culturelles de chacune de ces masses, il semble que, la communication entre ces deux parties ne soit pas aussi simple et naturelle que nous le souhaiterions.


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

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