DVau

Sur la liste des adhérents du Praxeme Institute, nous nous sommes livrés récemment à un petit exercice de modélisation sémantique. En voici le résultat.

Énoncé

L’énoncé est tiré d’une expression d’un besoin “métier” (en fait,une présentation par le Marketing) :

L’essentiel se joue dans l’aspect sémantique. En effet, le seul élément lié à l’organisation est le rôle “agent” dans la proposition “B”.

Client

Le rôle “Client” peut apparaître dans le modèle sémantique, sous la forme d’un rôle (au sens UML), c’est-à-dire d’un rôle sur une association (par exemple, vers Contrat ou Commande).

• La notion de client peut être perçue comme sémantique car elle n’implique aucune hypothèse d’organisation, comme c’est souvent le cas avec les acteurs externes.
• Cela n’interdit pas de revenir sur le rôle Client dans le modèle pragmatique , puisqu’il y a des décisions d’organisation à prendre : par exemple, droits accordés au client sur certains cas d’utilisation.

• Il faut surtout éviter de traiter les rôles par la classification (l’héritage). Cela expose au problème de la “mutation”. Une même personne peut être à la fois client et agent. Le principe de modélisation est ici : la substance arrive avant la relation. Les rôles (comme client) sont toujours relationnels, donc à traiter comme tels dans le modèle sémantique (cela n’interdit pas de réifier la notion de rôle dans le modèle pragmatique, puisque c’est justement une notion organisationnelle). La pure substance – ce que nous découvrons en observant le monde sans a priori et sans le reformuler dans une perspective interne -, la substance, dans notre exemple, ce sont les personnes.
• Le modèle générique (Open Business Concepts, pour reprendre l’expression de Fabien VILLARD) propose déjà la classe Party, laquelle couvre les cas : personnes physiques, personnes morales…

Les classes en jeu

On a donc :

• Party (d’où nous tirons le client et l’agent).
• Site, autre classe générique qui permet de traiter la sémantique des lieux comme des moyens de contacts (adresse, téléphone…).
• Period, également générique. A noter : à bien y regarder, les préférences sur le moment du contact ne sont pas si faciles à exprimer, si on les traite sur le long terme. La personne peut être disponible à certaines heures pour une période donnée et à d’autres heures pour une autre période. Elle peut exprimer des préférences avec des exceptions pour des plages identifiées. Ou encore, elle peut faire référence à un calendrier partagé (congés scolaires, jours fériés…). Il y a là un bon exercice de modélisation, aussi. Supposons cela traité. De toute façon, cela appartient à la sémantique de la période et doit donc être encapsulé dans la classe générique Period.

Réponse à l’énoncé A)

Une fois posées les trois notions – Party, Site, Period -, il nous faut examiner comment l’expression de préférences doit les combiner. Par exemple, on peut indifféremment :

• se donner P (un client) et T (un créneau), puis rechercher le lieu approprié, S = ce serait le cas pour un rendez-vous téléphonique ;
• fixer d’abord S, le lieu, et rechercher ensuite un créneau compatible = cas d’une rencontre physique.

Le modélisateur doit se dire, aussi :

• pour un P et un T, peut-il y avoir plusieurs S ? (oui = téléphone bureau et mobile ; à savoir : le téléphone mobile est traité comme un site)
• pour un P et un S, combien de T ? (plusieurs, là aussi)
• bien évidemment, pour un couple S (ex l’agence) et T (horaires d’ouverture), il y a plusieurs P potentiels (on espère : au moins un agent et un client).

De ces considérations s’impose la solution : il nous faut une association ternaire, reliant les trois classes Party, Site et Period.
Pas moyen d’y échapper car ce sont trois degrés de liberté dans la détermination des préférences spatio-temporelles.
Nous pouvons nommer cette association : “locates” (au sens de “répérer”), ce qui permet de respecter la convention pour les noms d’association (verbe à l’indicatif présent, 3ème personne du singulier). A noter : certains outils – et pas des moins populaires – ne vous permettent pas de nommer une association n-aire. Jetez-les !
Cette association doit être réifiée car elle porte des traits comme l’état (voir message de Fabien V.), peut-être le niveau de certitude, un commentaire, etc. Je l’appelle “Localization” (terme qui, en anglais, semble bien rendre la notion dont nous traitons ; ne pas confondre avec “location” qui est déjà placé sur le modèle générique comme rôle de Site dans l’association resides).

Réponse à l’énoncé B)

Faut-il compliquer le modèle pour répondre à la deuxième partie ? Non. L’agent est une personne. Son calendrier sera traité avec la même association. La ternaire permet de couvrir les cas de mobilité et travail à domicile.
Répondre au problème posé, revient donc :

• à fixer un P – le client ;
• à examiner ses préférences (couples de T & S trouvés par l’association “locates“) ;
• pour chaque couple, à déterminer si un agent (Party assumant le rôle) est disponible, en faisant appel à son agenda.

Donc, “B” n’ajoute rien en termes sémantiques. La question est : où placer le mécanisme correspondant ?
Une première réponse consiste à le situer dans un cas d’utilisation. Nous en trouvons un, au moins, dans le domaine Sales, plus précisément pour le Lead management (gestion des contacts).
En y réfléchissant, nous pouvons imaginer de nombreuses autres situations où ce calcul peut se faire (visite d’un expert, rencontre avec un partenaire, contrôle de chantier…). Reconsidérons la requête impliquée par la proposition B. Qu’y a-t-il, là-dedans, qui soit lié à une façon de faire ? à une organisation ? Rien. Nous pouvons donc considérer cette requête comme purement sémantique, plus exactement : appartenant au champ sémantique que nous venons d’étudier. C’est donc sous la forme d’une opération dans le modèle sémantique que nous la formulerons.
Où placer cette opération ? C’est le prochain exercice !

Cardinalités

Nous aurons du “0..*” à chaque extrémité, ce qui est un bon indicateur de la qualité de la solution…

Élargissement

Prenons, maintenant, un peu de recul ! Ce que nous venons de traiter pour des personnes, est-ce que cela ne ferait pas sens pour d’autres objets ? Par exemple : un engin de chantier, un drone, un spectacle… Certes, dans ces cas, il ne s’agit plus de préférences mais de planification. Pourtant, la forme de la détermination est la même. En conséquence, le modélisateur sera tenté de “faire remonter” la branche de l’association ternaire vers la classe Being, superclasse de Party. Le nom de l’association n’a pas à changer (ça tombe bien, nous n’avions pas choisi “Préférence” ; le terme “consultation” est trop lié à un usage donné et déborde le champ sémantique obtenu par la réunion des trois notions). La préférence – par opposition à planification, par exemple – sera traitée comme un état de la classe Localization.
Remarque : une telle généralisation a déjà été réalisée pour l’association “resides“.

Conclusion

La solution au problème énoncé repose sur l’association ternaire, à laquelle nous attachons une classe associative.
Beaucoup de problèmes apparemment anodins (comme notre énoncé) débouchent sur des solutions bancales ou amputées parce que le concepteur n’a pas vu le faisceau de déterminations. Refuser d’utiliser les relations n-aires (dans un modèle sémantique, s’entend), c’est s’obliger à estropier la représentation du réel. Une telle attitude condamne à développer des solutions inappropriées.
On oppose souvent à cette pratique de l’association n-aire que :

• elles sont difficiles à comprendre ;
• elles ne correspondent à rien dans la technologie.

Ces arguments ne tiennent pas. Il n’y a rien de difficile à considérer qu’une notion est déterminée par plusieurs autres. Pour le second point, se reporter à notre guide PxM-41, qui explique comment dériver un modèle sémantique en modèle logique de données.

Si de telles discussions vous intéressent, n’hésitez pas à nous rejoindre en adhérant à l’association.

A partir de cette année, les inscriptions individuelles sont gratuites et se font en lignes : http://friends.praxeme.org/adhesion/

Comment apprécier sérieusement une solution ?

Qu’il s’agisse d’une solution du marché (progiciel, ERP, package et autres noms) ou d’une solution interne (développement spécifique, maison), il n’est pas si simple de se faire une idée à peu près juste de la valeur et du comportement d’un logiciel.

Cherchant à mettre au point une méthode d’évaluation, je vous propose un premier jet sous la forme d’une carte qui, après raffinement et commentaire, débouchera sur une grille d’évaluation.

Tous les commentaires ou compléments sont les bienvenus.

Grille d'évaluation d'une solution informatique

NB : le code couleur n’a pas été arrêté au hasard !

En tant que méthodologie d’entreprise, Praxeme ne peut ignorer la notion d’objectif. Cette note répond à une proposition de Birol BERKEM, dans le cadre des activités du Praxeme Institute (voir l’illustration de son approche par les objectifs : “How to increase your business agility using the ‘Goal-Driven SOA’ process according to BMM and MDA”).

Les objectifs, comburant de l’entreprise

Certes informels, les objectifs condensent une part essentielle de l’énergie d’une entreprise, de la stratégie jusqu’au suivi quotidien en passant par les projets. Ils offrent un moyen de communication et d’élucidation des aspirations, à des degrés divers de maîtrise du contenu et de l’avenir. Ainsi, ils entrent dans des calculs et formules, des tâtonnements et commandements… en un mot, ils constituent les termes d’une dialectique toujours en marche dans les entreprises en pertuelle adaptation. Les objectifs fournissent le comburant qui permet au moteur de l’entreprise de fonctionner. Le niveau d’analyse et de formulation des objectifs appelle certainement des progrès importants, si nous voulons aider les entreprises à mieux se diriger. Ici, il faut dénoncer les déviations et trébuchements des approches par objectifs : slogans qui se vident de leur sens, contradiction ou dispersion le long de la ligne hiérarchique, confusion des genres (tout n’est pas stratégie), etc.

La place des objectifs dans Praxeme

Dans son approche totalisante de l’entreprise, Praxeme réserve une place pour les expressions qui ne sont pas susceptibles d’une formalisation complète mais qu’il est important de recueillir :

• expressions du savoir (les vocabulaires, les textes et procédures, les règles…) ;
• expression de la volonté (les objectifs, les exigences).

Cette place se positionne en amont des huit aspects à travers lesquels se structure notre connaissance de l’entreprise. Nous la nommons “cadrage” (ou scoping), d’après un terme proposé par Philippe DESFRAY. Il ne saurait y avoir d’autres positions :

• L’objectif inspire l’action, dont la transformation. Les expressions formelles et “actionables” viennent ensuite en réponse à l’objectif et s’inscrivent dans la théorie des aspects (“théorie” doit être pris ici dans son acception première : défilé).
• En conséquence, les modèles – quel que soit l’aspect – font référence aux objectifs. La position du “Cadrage” dans la Topologie du Système Entreprise est, d’ailleurs, très particulière : de toutes parts – à partir de n’importe quel aspect – un objectif peut être pointé. En effet, un objectif peut justifier n’importe quelle décision engrammée dans un aspect. Pour donner quelques exemples, une stratégie de banque-assurance consiste à étendre le modèle sémantique ; l’administration électronique repose sur une opportunité technologique ; une stratégie d’outsourcing va se lire dans l’aspect géographique…

Le méta-modèle

Quand le méta-modèle de Praxeme a été commencé (grâce à une contribution des Caisses d’allocations familiales), l’OMG avait déjà publié son Business Motitvation Model (BMM). Il a donc alimenté la réflexion. BMM est un modèle plutôt bien fait, en tout cas qui échappe au caractère verbeux et confus de beaucoup de méta-modèles. Il distingue les notions de goal et d’ objective, de stratégie et de tactique. En pratique, il est toujours délicat de faire la part de ce qui est stratégique et de ce qui est tactique – pour ne rien dire de la nuance entre but et objectif ! L’appréciation est assez subjective et dépend beaucoup de l’acteur. Ce qui est tactique pour l’un, sera stratégique pour l’autre. Dans la cascade qui s’écoule des objectifs stratégiques aux objectifs opérationnels, quel critère trouverons-nous pour arrêter les catégories ?

Pour échapper à ce problème bien connu des modélisateurs, le méta-modèle Praxeme a opté pour une seule notion – “Objectif” – dotée d’une association réflexive. En fait, cette association “justifie” est fusionnée avec la notion de traçabilité. C’est pourquoi son deuxième terme est la méta-classe “Représentation” qui recouvre également toutes les formes d’expression qui se distribuent sur les aspects. Le premier terme de l’association est la classe “Objectif”, sous le nom de rôle : “motivation”.

Figure 1 : Sémantique de Objectif (1ère version du méta-modèle – DVAU)

Dans la première version

Si elle est difficile à appréhender au premier abord, la compacité de cette modélisation a des retombées pratiques tout à fait intéressantes :

• elle simplifie l’outillage ;
• elle offre une plus grande liberté au praticien (pas de risque de se “tromper” entre goal et objective, entre stratégie et tactique ; il suffit de compléter l’information au fil du temps et de relier les instances de la même classe).

Il reste, bien sûr, à analyser les déterminations entre les objectifs (influence positive ou négative, composition d’objectifs…). Sur ce point, BMM fixe les notions. Leur réification sous la forme de classes dans le modèle n’est pas un service rendu au praticien. On lui préfèrera la solution donnée dans l’outil Modelio, où les objectifs se relient entre eux par divers liens typés : mesure, garantie, influence positive ou négative (voir le module Scope).

L’approche par les objectifs

Il y a beaucoup à dire de l’analyse et de la conception des objectifs. Ces activités sont en lien direct avec la conception stratégique et se prolongent à travers diverses disciplines de management, incluant l’innovation et débouchant sur le management par objectifs. Par cette seule catégorie de l’objectif, nous glissons progressivement de la stratégie à la gestion des ressources humaines.

Tous ces champs restent à arpenter. Ils doivent être labourés par plusieurs procédés qui s’intégreront dans la méthodologie d’entreprise. Nous ne faisons qu’entrouvrir la porte, ici. En revanche, il nous faut poser les limites à l’approche par les objectifs.

Les limites de l’approche par les objectifs

Il n’est jamais bon d’utiliser un outil à contre-emploi. L’analyse et la conception à base d’objectifs font merveille… tant qu’elles s’exercent dans leur champ nominal : le cadrage (scoping). Si on les transpose dans d’autres sphères, on s’expose à quelques difficultés. Vouloir structurer un système en termes d’objectifs, c’est la même erreur que de le structurer exclusivement en termes de fonctions. Nous sortons à peine de la dénonciation de l’approche fonctionnaliste, ce n’est pas pour la retrouver déguisée sous les traits de l’approche par les cas d’utilisation ou de l’approche par les objectifs. Bien sûr, les cas d’utilisation sont un outil efficace : pour autant que l’on décrive les activités du “métier”. Les utiliser pour structurer des systèmes entiers : c’est la catastrophe ! De même, les objectifs nous renseignent sur la politique de l’entreprise, ses préoccupations, sa volonté ; mais si l’on s’en sert en dehors du cadrage pour concevoir et structurer les autres aspects de l’entreprise, on aboutit à des structures qui ne présentent pas toutes les qualités requises (stabilité, faible couplage, économie…).

Il se trouve justement que les exemples d’objectifs sont souvent tirés du domaine du marketing (normal, puisque le barycentre du pouvoir dans les entreprises a tendance, de nos jours, à se stabiliser dans le département marketing – signe des temps !). Or, quoi de plus volatile qu’un objectif marketing ?

Figure 2 : Objectifs pour la gestion des contacts et opportunités commerciales

Lead Management

La volatilité n’est pas le seul contre-argument. Prenons l’objectif  “améliorer l’écoute du client”, lui-même contribuant à “développer les ventes”. Ce sont deux objectifs stables, voire éternels. Le premier s’inscrit dans une politique marketing qui soutient le second, objectif stratégique assez naturel. En quoi devraient-ils nous aider à structurer le  Système Entreprise ? Allons-nous instaurer un processus “développer les ventes” ? Le processus concerné est le traditionnel processus de vente. Nous pourrions avoir l’idée de restructurer les processus, sous l’impulsion d’un tel objectif, pour organiser une meilleure collaboration, par exemple. Mais nous n’aboutirons pas à “développer les ventes”. Si un processus s’apparente à ce dernier, c’est justement le processus de transformation : que faut-il changer dans le Système Entreprise pour que l’objectif soit atteint ? (C’est la définition même de l’activité de transformation à laquelle participe, entre autres, l’architecture d’entreprise.)

La réponse à une telle question passe par des ajustements du système existant ou par une réforme plus profonde. Le plus souvent, on ajoutera des indicateurs qui alimenteront les activités de pilotage ; on agira sur la culture autant que sur la structure…

Dans cette transformation, chaque aspect conserve sa propre logique. Chaque aspect possède son propre critère de décomposition. Nous ne gagnons que de la confusion à faire passer un critère d’un aspect à un autre (exactement ce qui est responsable de l’état de nos systèmes informatiques, structurés exclusivement en termes de fonctions). Le procédé proposé par Praxeme pour SOA (service oriented architecture) est très clair sur ce point :

1. L’aspect logique a sa propre logique de structuration (qui commence avec le principe de stratification).
2. Il conserve la structuration de la description “métier”, en séparant ce qui vient de l’aspect sémantique (cœur de métier) de ce qui est lié à l’organisation (aspect pragmatique).
3. Ces deux aspects ont des critères de décomposition différents (le domaine d’objets, pour l’un ; le domaine fonctionnel, pour l’autre).

Introduire l’objectif stratégique, tactique, opérationnel… dans cette équation n’ajoute rien. En revanche, maintenir la connexion entre telle décision de modélisation ou tel choix d’architecture, d’un côté, et un objectif, de l’autre,  oui, cela est essentiel pour apporter quelque lumière au travail de transformation et pour augmenter la rationalité du système.

Quelques exemples :

• Le modèle sémantique obéit aux lois de son aspect. Toutefois, il est notable que la restitution sémantique du concept de personne par opposition à la notion de client renouvelle l’approche marketing et contribue à l’orientation client.
• La façon de rebâtir l’activité de lead management (gestion des contacts) autour de l’automate de la classe Opportunité, et la conception ergonomique qui en découle répondent à l’objectif  “développer les ventes”.
• Les grands choix de l’architecture logique traduisent, d’une certaine manière, la stratégie d’intégration de l’entreprise.

Dans ces exemples, il n’est pas mal de garder le lien de justification ou de contribution entre les éléments de modèle et les objectifs.

On remarquera enfin, qu’une même décision de conception peut contribuer à plusieurs objectifs – dernière objection à une structuration du système par les objectifs.

Figure 3 : Un exemple d’analyse des objectifs

Lead management

NB : Les schémas ci-dessus ont été obtenus à l’aide de l’outil Modelio de Modeliosoft. Voir sur www.praxeme.org, les conditions de l’offre que Softeam fait aux adhérents du Praxeme Institute.

Quelques rapides éléments de réflexion sur ce thème.

Style des spécifications fonctionnelles

Aujourd’hui coexistent deux grands types d’expression de besoin :

1. classique, essentiellement spécifications textuelles en langage naturel, éventuellement « rigidifiée » par des structures de tableaux ou de renvois (si possible appareils de lecture automatiques) ;
2. avancé, avec tentative de formalisation pour assurer une meilleure qualité de spécification (réduction du volume, élimination des ambiguïtés, preuve de couverture…).

Ce deuxième style tire profit de la notation UML. Dans ce cas, la spécification se centre sur la notion de cas d’utilisation, qui reste marquée par l’approche fonctionnelle.
Certains dossiers d’expression de besoins se situent à cheval entre ces deux styles : ils adoptent une partie du vocabulaire UML (use-case) mais délaissent la notation et trahissent l’inspiration.

Les pratiques avancées structurent les dossiers d’expression de besoin, du moins la partie « fonctionnelle », en termes de cas d’utilisation, détaillés en scénarios et structurés par un vrai diagramme des cas d’utilisation.

Posture

Ce dernier point soulève une difficulté : dès que l’on introduit une technique de modélisation (ici, le seul diagramme des cas d’utilisation) pour relayer ou structurer l’expression textuelle, le rédacteur se trouve mis en demeure d’opter pour une des postures d’analyse ou de conception.

Traditionnellement, l’expression de besoins ressortit à l’analyse, uniquement : le rédacteur a pour tâche de décrire une réalité ainsi que des attentes. Mais, s’il se met en tête d’utiliser son outil de modélisation pour bien structurer son dossier, il commence à changer la structure du problème posé, en vue d’évacuer la redondance, d’augmenter l’agilité, etc. Ce travail l’amène à entrer dans la conception et donc, à s’écarter de la fidélité aux acteurs « métier ».
Cette frontière est déjà franchie quand on introduit, dans le dossier, des maquettes d’écrans – fussent-elles serviles et collées à l’existant.

Cette hésitation entre analyse et conception doit faire l’objet de toutes les attentions car la posture adoptée détermine le rôle du livrable dans la chaîne de transformation.

Place dans la chaîne de transformation

Ainsi, on ne peut pas élaborer le procédé d’expression des besoins en faisant abstraction de la chaîne de transformation dans laquelle il s’insère.
Le template même de Business Requirement dépend de ce qui se passe en amont et en aval.
Par exemple, un dossier peut mentionner les données (ce qui est un peu réducteur, soit dit au passage). Si la rédaction des exigences est précédée d’un effort de modélisation des objets « métier » (objets auxquels sont reportés les règles de gestion, les cycles de vie, etc.), le contenu du dossier de spécification s’en trouvera allégé.
De même, si le dossier est clairement perçu comme une expression d’analyse, le diagramme des cas d’utilisation qui s’y trouve sera considéré comme tel, ni plus ni moins. On prendra soin de ne pas considérer ce diagramme comme la structure de la solution. Il faudra, avant la réalisation, prévoir l’effort de conception, lequel produira un nouveau dossier des cas d’utilisation. Dans ce dossier de conception, on verra apparaître sur le diagramme des cas d’utilisation les relations qui permettront une bien meilleure structure.

Pour y voir clair dans la définition des livrables, le mieux est de croiser les deux critères :

1. Visibilité : externe (ce qui est perçu par les « utilisateurs » du système) versus interne (la solution, derrière la vitrine) ;
2. Posture : analyse (description du réel, sans intervention ; le rédacteur est à l’écoute des acteurs du système et en retranscrit les pratiques et les attentes) versus conception (imagination, invention d’une solution, y compris sur les aspects « métier »).

Quelles sont les conséquences de l’approche SOA sur l’organisation ?
Elles sont réelles et nous les avons expérimentées sur les projets. Il faut d’abord dire qu’il y a une ambiguïté fondamentale dans l’expression “projet SOA”. SOA est une approche d’architecture ; elle considère donc l’ensemble du système d’information. A l’opposé, un projet a toujours une portée limitée : il livre une application, répond à un besoin, est financé ou sponsorisé par une direction… Cette différence de portée entre l’approche SOA, d’un côté, et le mode de production par projets, de l’autre, appelle des dispositions particulières.
Ce thème a fait l’objet d’un chapitre du livre “Le système d’information durable”, chapitre qui n’a finalement pas été publié. Il vous est livré, ici : L’organisation de la DSI.

Sur la notion de portée, voir le Livre blanc (“SLB-02″) disponible sur le site www.praxeme.org.

Pour guider les travaux au sein de nos Collèges :

Besoin de distinguer trois types de documents, correspondant à trois niveaux de lecture :

1. le guide méthodologique – sur les justifications de la méthode, les principes sous-jacents, l’effort de rationalité… bref, de la philosophie (mais philosophie de l’action) ;
2. le document méthode ou la fiche méthode – qui, sur la base des principes, fournit la check-list que cherchent les opérationnels ;
3. la fiche outil – mode d’emploi qui traduit le document méthode (souvent, procédé) dans les termes d’un outil donné.

Il est essentiel de respecter cette typologie pour une bonne gestion du corpus documentaire. Chaque type de document intéresse des profils différents. Le style de rédaction diffère selon les types : du plus rédigé et argumenté au plus “pratique”. Les compétences des rédacteurs, également, changent d’un type à l’autre, associées respectivement aux métiers de méthodologue, d’ingénieur méthodes et d’outilleur.

Les documents méthodes ne doivent pas être marqués par un éditeur. Ils peuvent, en revanche, se référer à des standards (comme UML ou BPMN).

Passé le moment fugace de l’exaltation, nous sommes, assez naturellement et en vertu de la loi du moindre effort, enclins à éviter l’action. Comme à chaque fois que l’imaginaire populaire se trouve saturé par l’image de la crise, le prétexte est tout trouvé. Dans nos métiers, en tout cas, c’est une réponse facile et imparable pour éloigner les importuns :

• Monsieur, nous n’avons pas besoin de vos services, avec la crise les budgets ont été revus !
• Refondre le SI, vous n’y pensez pas ! Nous avons d’autres urgences.
• En pleine récession, pas question de perdre du temps à repenser l’organisation. On ne change pas l’équipage pendant la tempête…

Notez que, quand ce n’est pas la crise, d’autres arguments sont toujours à portée : le poids de l’existant, la stratégie d’outsourcing, l’orientation ERP, etc. Tout pourvu que l’on échappe à l’angoisse de la page blanche (sur la planche à dessin de l’architecte).
Cette remarque ouvrait la conférence “Méthode d’entreprise et transformation du système d’information en crise”, donnée le 30 avril à l’occasion des Assisses de la communauté Sustainable IT Architecture. Cela a été l’occasion d’aborder le thème :

Méthodologie et politique

La méthodologie d’entreprise doit-elle traiter de politique ?
Il ne s’agit pas de renoncer à l’exigence de rationalité qui caractérise la méthodologie. Au contraire, il est possible et souhaitable de transporter cette rationalité dans la cité et de l’exercer sur les problèmes du monde. Une partie des facteurs qui ont conduit à cette crise se trouve dans l’entreprise et les comportements que l’on y observe. Il est temps de s’y attaquer autrement qu’avec des discours moralisateurs et sans lendemain. Si nous voulons agir, la méthode nous y aidera.
La présentation commentée : Méthode d’entreprise et transformation du SI en crise

Politique et architecture d’entreprise partagent une même capacité à penser contre l’évidence massive et démoralisante.
Voilà un bon remède à la crise !

slb25-eameth Présentation (référence SLB-25) pour une conférence sur le thème “Enterprise Architecture: a method – How a comprehensive approach of the enterprise can really change our systems“.

Introduction de la conférence

Je commencerai par des évidences :

• principe d’abstraction (separation of concerns) ;
• nécessité d’un frameworkpour identifier les niveaux de préoccupation ;
• enchaînement des modèles.

Évidences ? Si on observe les pratiques, force est de constater qu’il n’y a pas toujours recouvrement entre les évidences du génie logiciel et les habitudes de travail !

Questionnement :

Quel framework utiliser ? Le fameux framework de Zachman que tout le monde cite et que personne n’applique ? Les quatre plans de représentation mis en avant par la plupart des courants de l’Enterprise Architecture ?

Le premier modèle prescrit est, dans presque toutes les méthodes, le modèle des processus “métier”. Très bien. Nous avons besoin de cette représentation de l’activité de l’entreprise. Une remarque toutefois : cette représentation était rangée, dans les méthodes traditionnelles, au niveau “organisationnel”. Effectivement, les acteurs y interviennent. On transporte dans les modèles de processus de nombreux présupposés organisationnels. Or, ces mêmes méthodes identifiaient un niveau plus abstrait : le niveau conceptuel. Il semble avoir disparu de nos pratiques et même de nos méthodes. Curieux, non ?

Vous devinez la suite. Le framework mis au point dans Praxeme :

• prend en charge le patrimoine méthodologique et en tire le meilleur, en l’actualisant ;
• tient le milieu entre les 30 cases du frameworkde Zachman et les 4 plans de l’Enterprise Architecture ;
• met en œuvre le standard MDA, jusqu’au détail des règles de dérivation permettant de passer d’un modèle à l’autre ;
• positionne précisément SOA et propose les procédés nécessaires à sa mise en œuvre ;
• ajoute la pré-modélisation (scopingou cadrage), de façon à couvrir toute la chaîne de transformation, de la stratégie au déploiement.

Évidemment, une présentation d’une demi-heure embrassant un domaine si vaste donne toujours une impression de théorie (et vous connaissez la répugnance générale que cela suscite). Pourtant, les Praxemiens savent bien qu’à chaque moment de cette chaîne, la méthode propose des procédés très précis, éprouvés sur plusieurs projets.

On peut se demander si une telle rigueur a encore sa place dans notre milieu professionnel. C’est une question qui sera débatue lors des Assises S-IT-A, le 30 avril 2009, sous le titre : “Méthode d’entreprise et transformation du système d’information en crise – La méthodologie d’entreprise doit-elle traiter de politique ?”.

Un recensement de quelques erreurs de conception des interfaces :

http://homepage.mac.com/bradster/iarchitect/shame.htm

Cela donne à réfléchir… en attendant de reprendre la réflexion sur l’ergonomie des logiciels.

L’observation des interfaces est un premier temps. La méthode propose ensuite un cadre structuré (voir post antérieur présentant les dimensions de l’ergonomie du logiciel). A partir de là, nous pouvons détailler le procédé.

On nous pose souvent la question du coût de l’approche SOA.

D’abord,  il convient de rappeler que, avec SOA comme avec n’importe quelle approche, les coûts dépendent avant tout du niveau de professionnalisme et de compétence des acteurs impliqués. Les “projets” SOA paraissent chers, surtout parce que les dépenses incluent le coût non isolé des tâtonnements, des errements, des discussions stériles et des essais malheureux.

Ensuite, évitons les mauvaises questions. Par exemple : faut-il réserver un budget important pour se lancer dans SOA ?

Ce n’est pas ainsi qu’il faut présenter le sujet.

Le budget des DSI est ce qu’il est : énorme. Pour quel service ? Entretenir des systèmes qui échapperont bientôt à tout contrôle ; faire vivoter des applications supportant un taux de redondance effarant ; handicaper l’entreprise en rendant impossible toute adaptation rapide.

La SOA étendue peut être pilotée comme une activité progressive. Avec le même budget mais un autre mode d’organisation, la DSI peut significativement améliorer le service qu’elle rend à l’entreprise et rapidement dégager des gains (hélas, comme toujours, nous manquons de chiffres sérieux).

Bien sûr, si le DSI peut obtenir un investissement supplémentaire pour mettre en place d’entrée de jeux les bonnes pratiques à l’occasion d’un premier projet, la transition devient bien plus facile.
Aujourd’hui, les risques et coûts de cette transition ont été considérablement réduits, du fait de la disponibilité de la méthode Praxeme qui apporte les réponses concrètes pour la refonte progressive des systèmes. Les entreprises n’ont plus à financer les tâtonnements méthodologiques ; elles ne doivent plus tolérer que leur personnel informatique perde du temps en querelle terminologique sur la définition du service ou sa granularité ; elles n’ont plus à affronter les conflits de reponsabilités entre les divers métiers impliqués dans la nouvelle approche des SI.

En conséquence, qu’elles obtiennent ou non une rallonge budgétaire pour leur premier investissement SOA, elles seraient impardonnables de choisir le statu quo.

Je reconnais volontiers que mon argumentation manque d’éléments chiffrés et scientifiques. Ce reproche doit être adressé à la communauté IT.