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...