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

Le concept d'objectif en entreprise

Un objectif devrait systématiquement être assorti de quelques critères de réussite, dont en voici six regroupées sous l'acronyme SMARTE :

• Simple
• Mesurable
• Atteignable
• Réaliste
• borné dans le Temps
• Écologique

Ce dernier point ajouté à l'acronyme bien connu SMART, mérite explication.
On entend par "écologique" l'ensemble, des facteurs qui prennent soin de ne pas porter atteinte aux personnes impliquées dans le projet, et qui garantie aux générations futures, de disposer en quantité et en qualité, des mêmes ressources que leurs ainés, pour leur développement propre. L’Architecture d’Entreprise serait elle épargnée par cette vague de fonds du développement Durable ? On peut aussi l’appréhender comme une véritable aubaine, au service de l’intérêt général.

Rappelons l’essentiel

• Pas d’objectif, pas de besoin. Comment parler de ces besoins, sans objectifs ?
• Des moyens pour les atteindre (indicateur).
• Des métriques pour les mesurer.
• Des acteurs motivés pour les réaliser.
• Une hiérarchie responsable, pour les définir et les suivre.
• Un diagramme d’Ishikawa pour les décrire, les formaliser et les jauger.

Objectif stratégique vs Objectif tactique

La définition des objectifs stratégiques est un art qu’il appartient, aux directions générales, d’établir. Il s’agit du support privilégié, pour promouvoir une vision à moyen ou long terme, pour cadencer la bonne marche de l’entreprise. Les objectifs stratégiques sont en général simples à exprimer afin d’être compris par tout le monde, et créer ainsi un effet d’entrainement. Pour autant sont-ils simples à décliner ? Non, les objectifs stratégiques ne sont en général pas mesurables, et nul ne sait, à priori, s’ils seront véritablement atteints ! Les organisations s’en remettent au charisme, et à l’expérience du « chef », ou une grande partie de son pouvoir, provient de son aptitude à faire gagner un collectif de personne bien polarisée. Les objectifs stratégiques sont plus qualitatifs que quantitatifs.
Devant ces constats empiriques, ou l’on voit bien que la superposition avec le modèle d’objectif idéal SMARTE, ne colle pas, nous comprenons, qu’après le rêve, il faut se retrousser les manches et entrer dans la dimension réelle du factuel et du mesurable. C’est la tout le savoir faire du tacticien. On entre dans le domaine des sciences de l'ingénieur.

Les objectifs ne prennent une dimension « tactique » que lorsqu’ils sont assignés précisément à un chef subordonné, dans le cadre d’un processus de réalisation, qu’il a la responsabilité de rendre efficace (voir efficient). Ces processus là doivent être décomposés en objectifs tactiques « SMARTE » pour en faciliter le pilotage et la communication ascendante: là, ça ne rigole plus, il y a négociation – mesure, délai, l’objectif est il « Raisonnable ». Beaucoup de possibilités s’ouvrent au tacticien, pour un objectif précis. Une possibilité sera soumise à l’approbation de la direction dans le cadre du « plan A ». Il devra également soumettre, au moins, une autre possibilité, en cas de coup dur, pour un plan de secours dit « Plan B ».

Enfin, précisons que dans les grandes entreprises, les directions subordonnées peuvent / doivent également construire leur propre stratégie. Un budget leur est alloué, accompagné d’une obligation de résultat. Ce découplage a joué historiquement en faveur du développement économique des grandes entreprises, prônant un mode de réussite basé sur la responsabilisation et la motivation des individus du groupe.

Processus, Procédures, Procédés …

Autant de concepts, porteurs d’un sens commun : Celui de « l’action dans l’organisation ». Comment s’y retrouver ?
Comme un bon schéma vaut mieux qu’un long discours, je propose un modèle simplifié permettant de mettre en relations, ces concepts, dans le cadre de référence de l’EA.



Processus
Le mot processus est d’origine latine. Il signifie « progrès, progression ». Dans le cadre économique de l’entreprise, il désigne le déroulement, d’un ensemble d’opérations successives, organisées, en vue de produire une valeur tangible pour son utilisateur (ou son organisation). Il transforme des données d’entrées en données de sorties, un peu à l’image d’une fonction, mais dont les contributions sont planifiées, cadencées, et ordonnées, dans des conditions maîtrisées selon un mode d’emploi, et contrôlables à tout moment.
Les processus métiers doivent être efficaces, à un moment donné, et devenir de plus en plus efficients. S'ils ne le sont plus, c'est que le contexte économique de l'entreprise a probablement changé.

Un processus peut être transverse à l'entreprise. L'analyse systémique de l'entreprise par l'approche des processus, permet d'identifier les interfaces entre les différents « métiers ».
Les éléments d'entrée d'un processus sont généralement les éléments de sortie d'autres processus. C'est ainsi qu'ils s'enchaînent. Ce peut être des données, des objets ou des évènements, contenu dans des flux. Le découpage d'un processus en tâches, en sous processus, ou en deux processus distincts, va dépendre de sa complexité, et par voie de conséquence, des responsabilités associées.

Le processus répond essentiellement aux questions : QUOI ? POURQUOI ?

Exemples : Quand il transporte ses passagers d’un aéroport à l’autre, le pilote fait un acte économique pour sa compagnie. Il est au centre d’un processus « Gérer un Vol » dont les objectifs sont : (C’est le POURQUOI)

• Faire gagner du temps aux classes « affaire »
• Faire rêver les vacanciers
• Justifier par la qualité du service, et l’ensemble des commodités, le prix très cher de certaines destinations.

Le QUOI : Vol, Appareil, Passager, Pilote, Aéroport …

Il est intéressant de préciser, que dans la vraie vie, un processus, comme "Gérer un Vol" n'est pas automatisable de bout en bout, même avec le pilotage automatique. La moindre boisson, ou jeu distribué aux passagers, fait l'objet d'une description dans une procédure.


Procédure
Le mot procédure désigne une série de formalités ou de démarches à accomplir, et/ou un ensemble de règles auxquelles il faut se soumettre, dans une situation déterminée, en vue de réaliser le processus cible. La procédure est donc un descriptif organisationnel détaillé à l’image d’un mode d’emploi, ou d’une recette possible à suivre scrupuleusement pour espérer remplir les objectifs du processus. Si la procédure n’est pas respectée, les données de sorties du processus ne seront pas conformes aux exigences attendues.
Une procédure d’entreprise, appelée également procédure métier ou procédure opérationnelle désigne :
- Un ensemble d'activités qui s'enchaînent de manière chronologique pour atteindre un objectif SMARTE.
- La procédure d’entreprise représente la manière de mettre en œuvre tout ou partie d'un processus métier.

A un et unique processus, peuvent correspondre plusieurs procédures :

• Il peut s'agir d'une procédure principale, accompagnée de procédures challengers et/ou complémentaires, Par exemple, pour le sous-processus de débarquement, on peut avoir : la procédure de débarquement « PLAN A» mettant en œuvre un satellite de débarquement, une autre procédure de débarquement, par bus, ou enfin la procédure de débarquement d’urgence, par activation des toboggans. C'est le « PLAN B »…

• ou il peut s'agit d'une procédure par type d'objet : par exemple les procédures "Check list" du même sous-processus "Décoller" sur Boeing n’est probablement pas la même que sur Airbus...

Remarque:
Le processus définit le métier de l'entreprise en faisant abstraction de son organisation sous-jacente, tandis que la procédure aligne le métier de l'entreprise sur son organisation.

Un des sous processus parmi les plus périlleux est « Faire décoller l’avion ». Pour faire décoller l’avion, le pilote doit suivre la procédure adéquat (sur Airbus A380) qu’il a appris à l’école de pilotage, et qui fait l’objet d’un guide précis : La check-list ».
La procédure répond, en plus, à la question : QUI ?


Procédé / Tache
Le procédé désigne une "méthode à façon" (ré)utilisée en vue d’obtenir un résultat déterminé. Les procédés qualifient les taches élémentaires d’une procédure.

Exemples :

• Des consultants de Softeam mettent au point d’intéressants procédés pour mettre en oeuvre la méthodologie PRAXEME.
• Il existe différents procédés pour mettre en oeuvre une Architecture de Service (SOA).
• Camille utilise des procédés mnémotechniques pour retenir les règles de grammaire.
• Clément a expérimenté plusieurs procédés chimiques dans ses cours de sciences.

QUOI ? POURQUOI ?
Le procédé répond de plus aux questions : QUAND? OU ? COMMENT ?
Le mode pilotage répond de plus à la question : Combien ?
Conclusion
Un processus au sens large, est caractérisé par les paramètres suivants:
1. La désignation d'un leader, des acteurs, des supports et des principaux moyens,
2. Les ressources requises (financière, humaine, matérielle...),
3. Les éléments d'entrée (données ou produits),
4. La valeur ajoutée,
5. Les éléments de sortie (données ou produits),
6. Le système de mesure, de surveillance ou de contrôle associé.
7. Une description succincte du processus,
8. Le ou les clients et fournisseurs du processus,
9. Les points de mesure,
10. Les moyens de surveillance,
11. Les objectifs.