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.

Panique dans le monde des trigrammes

Je profite de cette période de vacances pour poster un petit article détente.

Si vous prétendez animer ou participer à la Gouvernance du SI de votre entreprise, vous devrez réfléchir à cette proposition de vos consultants SI : "on vous propose d'être SOA compliant".

SOA compliant ?

Ce "buzz word" a deux significations dans le monde de la gouvernance informatique :
- Sarbanes-Oxley Act compliant (autrement-dit on vous parle de régulation financière)
- Service Oriented Architecture compliant (autrement-dit on vous parle d'architecture autour -à priori- de la gestion de la performance du SI par les services).

Grâce aux trigrammes on n'y comprend plus rien et on vous vend ce qu'on veut !

Rassurez-vous, on pouvait aussi écrire SOX compliant pour Sarbanes-Oxley, ou SOX compliant pour Schema Oriented XML, l'ancêtre de XML Schema, fondation de base des Web Services qu'on retrouve souvent dans la SOA (l'architecture, pas la loi).
On s'y perd.

Le bon et le mauvais XML

Avant-propos : dans la famille des XML-istes, je suis plutôt du type early adopter (voir le paragraphe History sur REST-art). Mais l'usage d'XML doit se faire au profit des utilisateurs, et cela nécessite quelques précautions.

Limitez les hiérarchies
Finalement la structure arborescente d'XML est un inconvénient quand les hiérarchies deviennent trop profondes.


<message>
   <contract>
      <customer>
         <enterprise>
            <contact>
               <personn>
                  <addresses>
                     <postal>
                        <zipcode>75008</zipcode>
                     </postal>
                  </addresses>
                  [etc.]


Les mécanismes de parsing seront plus lents et compliqués à déboguer, surtout en SAX. Les chemins (XPath) seront plus lents à évaluer. Et finalement le message XML ne sera pas vraiment lisible, non évolutif et souvent erroné (problème des références circulaires non exprimables sous forme d'arbre), contrairement à la promesse d'origine. Paradoxalement, avec des hierarchies profondes, ce sont les XPath qui sont simples à lire, ce qui ne sert à rien : "message.contract.customer.enterprise.contact.personn.addresses.postal.zipcode"

Limitez-vous donc à 2 ou 3 niveaux maximum, et privilégiez l'usage d'éléments de liaison et de référence (xlink ou plus simplement ref/idref).

Limitez le dictionnaire
La taille des noms d'éléments (tags et attributs) est aussi problématique : elle ralentira le traitement des messages (écriture, lecture, parsing), elle occupera plus de bande passante lors des transferts, et elle utilisera plus de disque pourle stockage.
Mesurez la place inutilement consommée pour décrire quelques informations :


<postalAddress>
   <streetNumber>12</streetNumber>
   <streetName>avenue des Champs Elysées</streetName>
   <addressComplement>esc C</addressComplement>
   <zipcode>75008</zipcode>
   <city>Paris</city>
   <Country>France</country>
</postalAddress>


Nombre de caractères contenant l'information : 48 octets.
Taille totale du message : 257 octets.

Là encore c'est paradoxal : un avantage de XML, sa lisibilité par l'oeil humain, devient un inconvénient dès lors que l'on souhaite utiliser XML pour faire dialoguer des machines. Et pourtant aujourd'hui, plus aucun oeil humain ne lit ou écrit du XML, la plupart des développeurs utilisant des générateurs (XmlBeans, Jaxb, JEE5, .Net, etc.).

Certains pourraient rétorquer qu'au lieu d'écrire "streetNumber" on aurait pu écrire "sNu" et, pour "streetName", "sNa", etc. Dans ce cas je ne vois vraiment pas ce qu'on gagne à utiliser XML.

Ce qu'il aurait fallu faire (attention ici on n'est plus dans du XLM valide) : puisque le XML bien formé impose des balises équilibrées, leur fermeture peut être anonyme. Imaginez le même message écrit de façon plus économe :

<postalAddress>
   <streetNumber>12</>
   <streetName>avenue des Champs Elysées/>
   <addressComplement>esc C</>
   <zipcode>75008</>
   <city>Paris</>
   <Country>France</>
</>


De plus, si le message qui suivra est décrit au même format, pourquoi rappeler ce format que le système consommateur a déjà rencontré ?

<postalAddress>
   <>12</>
   <>avenue des Champs Elysées</>
   <>esc C</>
   <>75008</>
   <>Paris</>
   <>France</>
</>


Je trouve cette proposition pas moins lisible (surtout si on a reçu au moins une fois le dictionnaire), et facile à convertir en "full-XML".

Ceux qui disent que le XML avait l'avantage d'être vérifié par le récepteur avant parsing seront encore plus heureux d'utiliser MD5 pour conserver des possibilités de vérification sans alourdir le message lui-même.

Pour ceux que l'évolutivité (la naturelle compatibilité ascendante d'XML) intéresse, aucun problème : ma solution ne supprime pas la notion de tag XML, elle permet de n'en transporter que les éléments essentiels, pas à chaque message. Il faudra néanmoins transporter un numéro de version de message, mais c'est une pratique que je recommande déjà en XML.

Pour utiliser une autre optimisation d'XML voyez par exemple BiTXml.

Restreignez-vous au strict minimum en XML
Si vous consultez la description du protocole HTTP (RFC2616) et de MIME (RFC2045), vous verrez que pour la plupart des échanges les formats sont standardisés. Vous constaterez aussi que le transfert de données simples est couvert par le type de contenu "application/x-www-form-urlencoded" (ex: streetNumber=12&streetName=avenue%20des%20Champs%20Elysees&zipCode=75008), et ces syntaxes sont des standards utilisés par tous les outils Web ainsi que les librairies associées dans tous les environnements (Java, .Net, PHP, Perl, C++, etc.).

Il ne reste au fond que des rares cas de données très structurées qui nécessitent l'usage de XML lors d'échanges M2M (machine to machine). Malgré cette évidence, les frameworks de développement de Web Services vous imposent l'usage de SOAP avec du XML auto-généré de manière opaque. .Net était déjà à l'extrême dans ce sens, JEE5 pousse le bouchon encore plus loin avec un comportement qui sera aléatoire selon le serveur d'application choisi (usage des annotations @Xxx).

Conclusion
Pour synthétiser, utilisez XML dans des messages à hiérarchie limitée (2 ou 3 niveaux), aux tags explicites mais pas trop longs, aux liens entre éléments réifiés, et uniquement si vous n'avez pas d'autre choix.
En définitive XML ressemble à une bonne idée non finalisée à utiliser exceptionnellement plutôt qu'à une solution universelle.

Pour plus d'arguments voir aussi le Guide d'usage de REST-art.

Cartographiez, Modélisez !

Boites et flèches, bulles et lignes, diagrammes, graphiques : tout est bon, tant que c'est adapté à l'interlocuteur.

Cartographiez les données, les systèmes, les applications, les machines, les salles, les flux, les liaisons : tout ceci vous permettra de mieux gérer l'existant.

Modélisez les processus, les données, les acteurs, les interactions, les réactions, les transactions, les règles de gestion : tout ceci est nécessaire pour comprendre les concepts et leur dynamique.

Cartographiez la liaison entre la cartographie et la modélisation (!) : pour connaître les systèmes mis en oeuvre dans les processus, pour connaître les données transportées par les flux, pour comprendre la chaîne de valeur de l'entreprise, pour révéler les chaînons faibles.

Cartographiez et modélisez l'existant : pour assurer l'exploitation, la poduction, la qualité de service.

Cartographiez et modélisez la cible : pour accompagner les projets, arbitrer les priorités, trouver les impacts des projets, pour assurer la transversalité des travaux en cours.

La liste est non exhaustive.

Quelques méthodes :

Avant-tout, la méthode de la méthode : soyez créatifs ! Un directeur général n'attend pas la même présentation qu'un chef de projet ou qu'un développeur. Utilisez des standards, mais uniquement à bon escient. Par exemple, face à un interlocuteur "UML-ophobe" sortir d'UML et passer 30 minutes d'effort pour redessiner un diagramme de façon plus lisible sera certainement payant. Par exemple encore, faire usage de couleurs remarquables, de mise en relief, de jeu sur les tailles, etc.
Votre objectif est de faire un focus sur quelques activités ? Supprimez les détails techniques du processus ! Votre objectif est de faire un focus sur les concepts utilisés ? Supprimez l'UML, faites une liste à plat ! Votre objectif est de montrer des regroupements par catégorie ou par package ? Faites un arbre façon explorer ! etc.

Boites et flèches : UML, BPMN, etc. "Boites et flèches", c'est le langage commun du modélisateur.




Boites et courbes : petite variante bien pratique pour montrer la dynamique : une courbe se suit plus naturellement que des segments de droite, et avec moins de confusion.








Bulles et lignes : pour sortir du côté rectiligne des boîtes. On peut de plus jouer sur le diamètre des bulles.







Flux et swimlanes : d'un simple coup de souris, pour donner une qualification ou une catégorisation globale.








Cartes et plans : analogie avec l'urbanisation (la vraie !), pour attirer l'oeil vers un format "déjà vu".













Plan de métro (croisement entre "Cartes et plans" et "Bulles et lignes") : pour montrer les liaisons (correspondances), les indicateurs ou activités (stations), les hypothèses de départ et les objectifs (terminus de départ et d'arrivée), etc.








Et il y en a encore plein (3D, Etoiles, Spirales, Cibles, ...).

Il n'y a pas de représentation unique pour communiquer ou faire comprendre autour d'un diagramme. Il y a la (les) vôtre(s), et celle(s) de vos interlocuteurs.


Mais souvenez-vous : quelle que soit la forme : Cartographiez, Modélisez !

---
Quelques liens :
Proposition de Philippe Dias (plans de métro)
BPMN et aussi ici et sur Wikipedia.
UML et sur Wikipedia