24 décembre 2007

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.

11 décembre 2007

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.