Quand la politique (d'entreprise) s'en mêle

Vos décisions d'urbaniste ne sont pas écoutées, prises en compte, ou restent sans effet ?

La gouvernance d'un SI est un jeu subtil.
Créez un système ou une application, et les vautours s'en empareront.
Tentez une fusion entre deux systèmes, et les vautours vous en empêcheront.

Puissance et gloire à qui est responsable d'une application, d'un système, d'un batch, ou même d'une simple table : il pilote un budget, des ressources, des besoins exprimés, des roadmaps proposées. Opacité et chiffrages exagérés faisant bon ménage, la machine s'emballe, et la maintenance évolutive ou fonctionnelle du système, qu'on essaye de placer comme maillon essentiel de tout projet de l'entreprise, devient une activité très rentable (pour le CV du chefaillon) : participation à des gros projet, pilotage d'un budget immense, d'une équipe qui se compte en dizaines de personnes. En bref, l'eldorado du middle management.
Et comme notre chefaillon n'est pas seul de son espèce, l'éco-système de type jungle profonde (avec les lianes et les piranhas) se propage dans l'entreprise.

Ces chefaillons ont-ils des chefs ? Souvent, oui. Et si le niveau du dessus n'est pas plus intègre (je n'ose dire honnête), il verra vite son intérêt à diriger ces sommes de budgets et d'équipes (super-puissance, super-gloire). Vous vous retrouvez face à une fédération de petites baronnies, ingouvernables, où toute décision ressort plus de la diplomatie que du respect du client (voire de la sauvegarde de l'entreprise)...
Vous savez, le client de l'entreprise, celui qui donne - pour de vrai - de l'argent, et qui aimerait entendre autre chose que "c'est pas nous, c'est une panne informatique". C'est justement au nom du client qu'il faudra proposer des actions de remise en ordre du système.

Mettez un urbaniste (ou une quelconque personne de bonne foi) au milieu de ce panier de crabes, il ne fera pas long feu. Il sera soit évincé de toute décision, soit manipulé par l'un ou l'autre de ces petits chefs cherchant à mettre la main sur un nouveau système.

A ce niveau, pour sauver l'entreprise et les promesses faites au client, quelques actions s'imposent :

• impliquer l'actionnaire, lui montrer l'impact de ce fonctionnement sur le client ;
  
• objectiver le DSI sur les coûts (DSI = cost killer) ;
• missionner quelques consultants externes pour révéler l'impact négatif des baronnies sur l'activité commerciale de la société (audit par une autre branche de l'entreprise, par une autre filiale du groupe, par un cabinet indépendant, etc.) ;
• lancer une politique de restriction du nombre d'applications ou systèmes qui participent au SI ;
• renforcer les équipes transverses du SI (contrôle de gestion SI, cellule d'urbanistes, gestionnaires de projet ou PMO, pôle d'exploitation SI, etc.), surtout face à la prolifération de petites équipes gérant 1 à 2 applications chacune ;
• interdire (en COPIL, COPROJ, CODIR, CO-ARCH, CO-URBA, ...) l'emploi de termes du type "trop compliqué pour toi", "on ne sait pas comment c'est développé", "on a toujours fait comme ça", etc. ;
• reformuler les objectifs de tout responsable d'équipe, notamment (a) contribution à la création de bénéfice et non de chiffre d'affaire, (b) objectifs quantifiés d'outsourcing, (c) objectifs quantifiés d'urbanisation (flux normalisés, processus modélisés et mis en oeuvre, etc.).
  

Pour finir, quelques phrases qui doivent vous mettre la puce à l'oreille :
"Pour écrire cette fiche d'évolution ? Il me faut 5 jours minimum."
"Cette action débutera le 15 décembre, sur le budget de l'année en cours."
"On ne TOUCHE PAS à mon périmètre !"
"Ça ? c'est très compliqué, seule mon équipe est compétente."
"Je ne pense pas qu'un urbaniste puisse me dire ce que je dois faire."

XML : 10 ans déjà

Mes lecteurs les plus fidèles (s'ils existent !) auront noté que je n'accorde pas à XML sa qualité de panacée que d'autres ont parfois tendance à proposer, avec exagération selon moi.

Toutefois, sans XML, où en serions-nous ?

Eh bien, sans-doute au même endroit :

En 1998 les formats arborescents et auto-décrits étaient déjà à l'étude ici où là, avec des implémentations proposées. A cette époque - avec Jean-Michel Dussoux - nous avions inventé le FDEC qui rend encore de nombreux services chez Bouygues Telecom. Nous avions décidé d'éviter ASN.1, mais c'était toutefois une proposition convenable. Tuxedo avait son buffer FML. WebMethods était un early adopoter d'XML, mais Active Software travaillait sur un langage de description de messages faisant référence au dictionnaire stocké dans un repository de l'EAI. La réflexivité, qui inclut une description des données échangées, était déjà en service dans Corba (découverte dynamique), etc.

Bref, XML s'est imposé - et c'était incontournable - mais un autre aurait pris sa place si XML ne s'était pas présenté. Dans un environnement aussi propice à l'avènement des échanges B2B et à la recherche d'une souplesse pour les échanges de messages, c'était certain.


Allez, je suis honnête : XML n'est pas toujours parfait, mais c'est souvent ce qu'il y a de moins pire.

Accepter la régression

Nous vivons une époque formidable : le temps est venu de refondre nos systèmes informatiques !

Après des années de développement sur des terres vierges, les DSI actuels sont tous confrontés à une nouveauté : le remplacement des applications obsolètes.
Les programmes de refontes, pour se débarrasser des anciens systèmes devenus encombrants et moins ouverts que leurs potentiels successeurs, sont légions, et les techniques pour y aboutir sont tout aussi nombreuses.

Je ne compte plus les stratégies.

Le « big bang » : on passe d’une application à une autre en une nuit blanche après 3 ans de développement, ce qui aboutit le plus souvent à un gros bang : fin de la refonte, fin du DSI.
La « juxtaposition remplaçante » : le remplacement progressif, par exemple de trois applications par une autre, mais sans big bang, revient à créer une quatrième application qu’il faudra un jour remplacer.
Autre type de juxtaposition, le « décentrage » : on adresse avec la nouvelle application un processus nouveau, qui n’était pas couvert par l’ancien système (on n’a rien remplacé, mais on se congratule).
Le remplacement « technique iso-fonctionnel » : ça c’est merveilleux, la maîtrise d’ouvrage va payer des (dizaines de) millions pour avoir... la même chose qu’avant, mais en Java au lieu du COBOL (bel effort !).

Bref, je critique mais j’ai participé à chaque stratégie... Le point commun de l’ensemble de ces stratégies est qu’elles permettent d’éviter la régression, ce gros mot qui fait frémir les responsables informatiques.

Force est de constater qu’éviter la régression c’est éviter la refonte.

La culture de la régression est pourtant présente dans notre quotidien : changement de lunettes (aveuglement dangereux pendant une journée), changement de véhicule (freinage à réapprendre), changement de traiteur chinois (...).

La refonte informatique ne se passera pas sans régression, c’est une certitude, et c’est le seul élément à partager avec l’ensemble de l’entreprise, y compris les futurs utilisateurs. La régression s’explique par l’absence de documentation exhaustive de l’application à remplacer, par la présence d’habitudes ou de systèmes locaux qui contournent les défauts de l’existant, par une culture orale qui s’est dissipée avec le départ des concepteurs de l’époque.

Bref, la régression c’est naturel.

Alors prévoyez : la régression, partagée avec le métier, anticipée avec l'ensemble des acteurs, c’est la réussite de votre projet de refonte. Concentrez-vous sur les processus critiques (les vrais), ainsi que sur les apports nouveaux et les gains tangibles, apportés au métier par votre refonte (en dehors du Java ;-).
Et notamment : les nouvelles lunettes ont des verres ultra fins, le nouveau véhicule pollue moins, quant au traiteur chinois...

L'Urbaniste SI et le Projet

Il est navrant de voir qu'aujourd'hui encore on trouve un grand nombre d’acteurs des DSI qui considèrent que l'Urbaniste SI est "en dehors du concret".

Voyons pourquoi, comment, et quels seraient les remèdes.

Le projet est la première victime de l'Urbaniste

Il faut se rendre à l’évidence : les propositions d’urbanisme peuvent pas casser ce qui fonctionne dans le SI. Elles doivent s’appuyer sur les projets pour planifier la construction du SI. L’Urbaniste, prenant en compte une vision globale et pluri-annuelle du SI et des besoins métier, n’a que les projets opérationnels pour la mettre en œuvre. Même s’il existe des chantiers d’infrastructure, qui portent uniquement les besoins des Urbanistes, l’étape d’après sera de faire accepter aux projets d’utiliser cette technologie.

Donc dans tous les cas, c’est bien le projet qui doit assumer les décisions des Urbanistes.
On entend alors poliment : "je n’ai rien contre l’Urbanisme, mais là on doit être efficace.". Car le projet, s’il n’a pas été dès le début prévu pour accompagner les objectifs de l’Urbanisme, va nécessairement avoir un certain rejet de décisions externes imposées à la dernière minute.

L'Urbanisme serait-il la dernière roue du carrosse ?

Si l’Urbanisme a été vécu comme une surcouche non efficace et imposée – donc inutile et coûteuse, il sera supprimé du périmètre du projet en cas de réduction du budget. Il faut être logique : imposer à un projet une décision non partagée, c’est l’assurance qu’elle soit abandonnée en cas de réduction budgétaire. Or les budgets des projets sont toujours réduits.

Pourtant ce n’est pas une fatalité : l’urbanisme ne serait pas la dernière roue du carrosse s’il accompagnait plus finement les projets, dès l’expression de besoin et le choix de la solution.

Y aurait-il de mauvais Urbanistes ?

Effectivement, le rejet des propositions d’Urbanisme n’incombe certainement pas uniquement au projet. Prenez un urbaniste dans sa tour d’ivoire, réalisant son plan d’urbanisme sans échanger, sans communiquer, sans préparer le terrain… Le jour de la mise en œuvre, il sera évidemment confronté à un problème d’accompagnement de ses propositions ou de conduite du changement.

Oui, il y a donc de mauvais Urbanistes.

Mais comment les détecter, puisqu’ils invoqueront toujours la faute du projet qui n’a pas voulu accepter les propositions ?

L’Urbaniste doit participer au projet…

Je parle par expérience. Pour détecter le mauvais Urbaniste, comme pour faciliter la prise en compte des propositions d’urbanisme dans les projets, une seule solution : l’immersion.

Prenez un Urbaniste compétent, qui a le souci de donner à chaque projet des clefs pour son intégration dans le SI. Mettez-le dans le projet, très en amont, avec des propositions prêtes à l’emploi (mais non gravées dans le marbre) pour faciliter la description des interfaces du produit. Cet Urbaniste aura préparé une déclinaison du Plan d’Urbanisme SI pour ce projet. Il aura entre les mains quelques modèles de processus et de données (qu’il aura captés chez les métiers). Mettez-le en contributeur actif des spécifications d’interface, d’échanges, de flux, d’intégration avec le reste du SI, etc. Demandez-lui aussi de participer au lotissement du projet, des phases de mise en œuvre du produit, etc.

Une fois ces spécifications réalisées, laissez l’Urbaniste dans le projet. Un bon urbaniste doit comprendre ce qu’il doit proposer, et pourquoi ses propositions seront confirmées ou abandonnées. Un très bon Urbaniste comprendra avant-même le projet quelles propositions d’urbanisme pourront être apportées à un projet, en fonction du contexte, en fonction du budget, de l’urgence opérationnelle, etc.

… et inversement

Inversement, il y a des équipiers projets qui ne veulent pas écouter ce que l’Urbaniste a à dire, et pourquoi il le dit. Tout acteur du projet devra comprendre qu'il n'est pas seul, et que le fruit de son projet doit s'inscrire avec un succès durable dans un SI existant, ce qui exprime les raisons et motivations des Urbanistes. Le projet (le build) est une phase transitoire, le produit (le run) est une phase plus longue : les opérationnels - les métiers - vivent des produits, et non des projets.

Idéalement, l'acteur projet sera immergé une fois de temps en temps dans la cellule d'Urbanisme : il participera à la construction du plan d’urbanisme, il réfléchira aux notions d’interface, aux questions autour des modèles, et apportera sa contribution à l’Urbanisme.

En conclusion

Notre métier d’Urbaniste est souvent mal vécu par les « opérationnels », alors que les objectifs sont à l’origine les mêmes : un SI efficace répondant aux besoins et enjeux stratégiques. Il n'y a pas d'Urbanisme sans projet.

Un conseil aux Urbanistes : soyez d’abord un opérationnel, réalisez des projets, avant de vous mettre à l’Urbanisme. Puis revenez souvent au projet.

Un conseil aux acteurs projet : ne confondez pas pieds sur terre et terre à terre (le premier est nécessaire, le second est néfaste). Pensez-y : les Urbanistes sont le plus souvent issus des projets, et y replongent régulièrement (si ce n'est pas le cas, invitez-les !).

Dans l’univers de l’entreprise où tout va très vite, et où le SI est un partenaire incontournable, il faut conserver une vision long terme, une sorte de sang-froid, qui permet de définir et de maintenir un cap. C’est un peu le rôle de l’Urbaniste, et c’est aussi pour cela qu’il est parfois incompris. Mais il est nécessaire.

REST un peu plus reconnu

Que les choses soient claires : j'ai été un early adopter de SOAP. Dès 2000 j'ai été l'auteur d'une librairie écrite en C++ et Java qui implémentait SOAP (ref). Ce protocole était à l'époque une proposition assez bien accueillie par la communauté des développeurs. Mais force est de constater que les défauts de SOAP n'ont jamais été corrigés, et que l'usage généralisé de ce standard de facto n'a pas permis d'améliorer les propositions.

Qui en effet saurait dire ce qu'est une SOAPAction ? Quelle différence avec l'URL ou la méthode ? Comment expliquer qu'on ne saura pas dire quel service est réellement invoqué en ne regardant que l'URL ? Que peut contenir réellement l'entête ? etc. Je laisse les adeptes de la génération automatique (et opaque) répondre que tout ceci est inutile car les générateurs de code font tout à notre place... heureusement d'ailleurs. Mais pour ceux que le fonctionnement intéresse, au-delà du générateur opaque, point de salut, sauf à limiter l'usage de SOAP et revenir à des échanges plus simples mais tout aussi inter-opérables et orientés web services : REST.

C'est l'objet de propos tenus récemment à "Paris On Rails" (d'où l'écriture soudaine de ce message).
Cela fait longtemps que je prône moi-même l'usage de l'architecture de Mr Fielding, j'en ai même fait un petit [micro?] framework Open Source : REST-art.

Le bon et le mauvais XML (suite)

Bis repetita...

Cela fait plusieurs fois que je donne mon avis sur ce sujet, et déjà il y a quelques temps, partiellement, sur ce blog. Voici donc dans le détail un peu d'explication sur les "profondeurs de XML"...

Je reçois ce jour la question d'un collègue et ami :

Si fonctionnellement on a ça :


Alors techniquement on peut avoir ça :


Et donc en XML l'adresse est "imbriquée" :

Est-ce correct ? La recopie avec des imbrications à " l'infini " pose problème, ne serait-ce que la lisibilité du fichier XML, non ?

Ma réponse :
En Java (par exemple) la classe sera définie avec une référence à Adresse :
public class Personne {
private Civilite civilite;
private String nom;
private String prenom;
private Adresse adresse; // <- ceci est une référence vers une adresse (ie: l'objet n'est pas dans la classe personne)
}

On aura d'ailleurs :
public class Adresse {
private String num;
private String voie;
// etc.
}

En XML la notion de référence n'est pas native, ce qui fait qu'on a parfois l'impression (seulement l'impression) qu'on doit imbriquer les niveaux :

Ce XML est valide et utilisable dans un message, oui mais...

Les inconvénients d'une telle pratique sont :
1) Jusqu'où aller ? quelle profondeur notre arbre aura au final ? (ie : message.contrat.contractant.personne.adresse.voie. ... , on peut parfois aller loin comme ça !)

2) Comment référencer la même adresse sans la recopier ?
3) comment avoir la même souplesse qu'en Java : une simple référence vers un objet Adresse depuis un objet Personne qui reste simple ?

Il a donc été créé en XML la notion de référence (id/idref ou key/keyref).
Donc la bonne idée est la suivante :


On est toujours en XML valide (penser à englober les 2 éléments dans un élement de plus haut niveau, par exemple ). C'est un mécanisme standard et conseillé mais peu usité car les développeurs ont tendance à préférer des formats très arborescents, ce qui est une erreur pour la lisibilité et l'évolutivité des messages.

Subsiste alors une question : id/idref ou key/keyref ?
La différence :
Dans id/idref , id est un identifiant local au message (ex: "adresse1"), qui n'a aucun sens en dehors du message.
Dans key/keyref, key est une clef externe au message (ie: numéro de compte client, identifiant de contrat, etc.).
La question du choix entre id et key est très importante, et il convient de n'accorder aucun crédit aux réponses absolues du type "toujours key/keyref" (source: O'Reilly). Il faut, selon le cas, choisir l'un ou l'autre.

Guidelines :
-> Utiliser key/keyref c'est se donner l'avantage de la cohérence (en cas d'incohérence une simple requête au référentiel suffira à retrouver l'information). Typiquement : un n° de contrat, un n° de client, un id de transaction, un code pays.
-> Utiliser id/idref c'est garantir qu'on limitera les niveaux d'arborescence (= garantir l'évolutivité et la lisibilité [par le logiciel] des messages), même si les objets référencés n'ont pas d'identifiant unique déclaré. Cette technique est typiquement utilisée pour des objets plus volatiles : une adresse ou tout type de coordonnées, le résultat d'un calcul ou d'un contrôle, etc.

Pour aller encore plus loin :
On suggère de réifier chaque relation (ie: la flèche, dans le diagramme UML, devient un objet XML, du type , et qui peut utiliser des id/idref), afin d'être encore plus évolutif.

Parfois plus difficile à construire, mais tellement plus viable !

On peut aussi utiliser xlink, etc.

Autrement dit, le champ des possibles est vaste, mais on peut commencer par privilégier id/idref ou key/keyref.

A qui appartiennent les [modèles de] Processus ?

A qui appartiennent les [modèles de] Processus ?
Question saugrenue ou véritable problème organisationnel ?

Tout d'abord, à qui appartiennent les Processus ?

Hypothèse : les processus appartiennent aux métiers.
Les processus appartiennent aux métiers, donc à ceux qui les vivent. Cela semble vrai et efficace : le propriétaire, le gestionnaire, l'administrateur, le pilote, le référent, (etc.) du processus est un acteur métier. Cependant c'est une information presque inutile, puisque le processus ne peut être manipulé, modifié, amélioré, étudié, (etc.) que s'il est modélisé.

A qui donc appartiennent ces modèles de processus ?

C'est une question qui existe dans toutes les organisations, et qui renvoie l'image de la difficulté qu'on a à opérer de façon transverse. Si le processus est transverse, la gestion du modèle l'est , elle, parfois un peu moins.

Les métiers de qualiticien, de stratège, de pilote opérationnel, d'exploitant ou d'architecte SI utilisent tous des modèles de processus. On est même parfois confronté à des modèles différents en fonction de ces métiers, voire de l'usage qui est fait du processus.

Si l'on décrète que la Qualité est propriétaire des modèles de processus, comment garantir que l'architecte SI, sans avoir le droit de redessiner le processus, pourra faire son travail ?
Si le métier possède les modèles de processus on va tomber dans le même travers : une représentation unique destinée à piloter l'activité, mais pas à destination des entités support.

La solution passe par la tolérance
Cinq minutes de tolérance. Vous passez devant un bureau et surprenez un dissident en train de modéliser un processus sans mandat officiel...
Votre réaction ? Virez-le !
Non, essayez de comprendre ses raisons : on n'a jamais tort de redessiner un processus dans son coin, on aurait juste tort de croire qu'il fait foi.

La solution passe aussi par la collaboration
L'étape suivante est la collaboration dans la modélisation de processus : ne gardez pas votre savoir enfermé en lecture seule dans votre référentiel de processus (ou dans ce qui fait office de référentiel). Si une équipe, ailleurs dans l'entreprise, apporte sa modeste pierre à l'édifice, acceptez-là comme un enrichissement.
Il y a autant de modèles de processus qu'il y a de métiers qui les utilisent, et votre référentiel, si bien constitué qu'il soit, ne pourra donc pas tous les contenir.

Définir le langage métier de l'entreprise
L'important au fond est de savoir de quoi on parle, et de fixer au minimum le vocabulaire métier. Pour cela le référentiel devra contenir les listes de termes décrivant vos processus : si "acquisition client" est le nom d'un processus, vous devrez expliquer pourquoi ce nom devrait remplacer, si possible, les autres (tels que "vente", "acquérir client", etc.), afin de vérifier qu'on parle de la même chose. Vous définirez aussi "client", vous direz qu'est-ce qui caractérise une "acquisition", et si d'autres objets métier sont importants pour ce processus. Vous trouverez grand nombre des objets métier importants dans les indicateurs de performance du processus (définis conjointement par la Direction, la stratégie et les acteurs du processus). Vous devrez ensuite accepter modestement que dans votre référentiel le modèle de ce processus, représenté par un diagramme, n'est qu'une illustration.

Propriété collective
Les modèles de processus appartiennent à ceux qui les utilisent, ils peuvent varier d'une entité à une autre. Ils doivent respecter le langage métier de l'entreprise, ou expliquer pourquoi ils divergent de ce langage, si c'est leur finalité (dans le cas d'une conduite de changement par exemple).

Et surtout, restez modeste : les modèles de processus sont toujours un peu faux.