Les règles d'or de l'architecte d'entreprise : #7, les chiffres tu utiliseras

Si je devais résumer mon travail de manière la plus simple possible, je dirais que je réalise deux types d'activités : des diagnostics d'architecture et l'élaboration de nouvelles architectures.

Dans les deux cas je mouille la chemise, dans le sens où je donne des avis engagés et tranchés (rappelez vous ma règle d'or n°4, je hais les consensus mou) et donc je suis en permanence confronté à la nécessité de convaincre mes interlocuteurs.

Ce qui m'amène à ma septième règle d'or dont j'ai petit à petit pris conscience. Beaucoup d'architectes sont passionnés par leur travail, ce qui est très bien, mais ils traduisent cette passion par des opinions tranchées (ex : "les web services c'est nul", "si ce n'est pas asynchrone, ça ne marchera jamais", …). Or, il n'y a rien de pire qu'un débat d'opinions pour tourner en rond. Il faut revenir aux faits.

Comment factualise-t-on un avis sur une architecture ? Je pars du principe qu'il y a toujours moyen de quantifier les choses quand on s'en donne la volonté. Je vais prendre un exemple issu de ma propre expérience pour l'illustrer.

Revenons quatre ans en arrière avec une mission que j'ai menée pour un acteur majeur de l'énergie. L'objectif principal de la mission, pour faire simple, était de diagnostiquer l'architecture "à bout de souffle" d'un système critique en vue d'élaborer une trajectoire de transformation. Le client avait engagé depuis plusieurs mois des travaux de modernisation sur une partie du périmètre, en s'appuyant sur une solution de Business Process Management. L'investissement était significatif (plusieurs millions d'euros) et cette solution était considérée comme un précurseur de la future modernisation de l'ensemble du système. Donc en toute logique, j'épluche les documents de conception et j'organise des interviews des porteurs de cette architecture. Et là, rapidement je vois qu'il y a un hic, j'ai la conviction de l'architecture de cette nouvelle solution ne tient pas la route alors même que ceux qui me la décrivent sont très fiers du résultat.

Je fais un pas de côté et je prends un peu de recul : le management a engagé plusieurs millions dans cette solution et il y a une trentaine de personnes qui ne vivent que pour ça depuis plusieurs mois. Il va falloir que j'aiguise bien mes arguments pour leur expliquer qu'il faut tout jeter à la poubelle. D'où la nécessité de me baser sur des faits, et uniquement sur des faits.

Quel est le fond du problème avec cet architecture ? La solution BPM a été utilisée à contre-emploi, elle a été "tordue" comme on dit dans le milieu, ce qui présage d'une maintenabilité et d'une évolutivité médiocres, et fait peser des risques sur la scalabilité, surtout si on généralise cet usage sur un périmètre plus large.

J'ai donc construit une argumentation pédagogique, étayée par des chiffres :

1. Revenons aux basiques : quels sont les objets standards d'une solution BPM (les activités, les tâches, les tables de décision, les interfaces, etc.) et les moyens de customisation (scripts, formulaires, …) ?
2. Quel est le cadre nominal d'utilisation de ces standards dans la solution retenue ?
3. Quelles sont les métriques d'utilisation de chaque concept de la solution BPM dans l'implémentation ?

Vous voyez où je veux en venir ? Faire comprendre que l'on a totalement dérivé d'une implémentation standard. Pour l'étape 3, j'ai développé quelques scripts d'analyse des artefacts d'implémentation (avec mon ami python) qui m'ont permis d'exposer des métriques irréfutables sur le volume d'usage de chaque concept. Ce qui a démontré par A+B que l'implémentation a dérivé des concepts standards pour aller massivement sur de la customisation :

• Seul 1/4 de l'implémentation s'appuie sur des objets standards
• Près de 100 000 lignes de customisation ont été implémentées avec un langage de script propriétaire à peu près aussi puissant que VBA (j'ai également factualisé les limites du langage pour enfoncer le clou)

Le coup de grâce : la solution coûte plus de 500 000 euros de licence annuelle. C'est tout de même dommage de payer ce prix-là pour n'utiliser qu'1/4 des capacités standards du produit.

Je ne vous cache pas que la restitution a été "chahutée", mais mes arguments ont tenu. L'équipe a mal accueilli l'analyse, ce qui est humain, mais n'a pu réfuter les chiffres. Le management a lui très bien compris le problème, et la décision d'abandonner cette solution a été prise en quelques jours.

Mon exemple est parlant pour les activités de diagnostic, mais la règle s'applique également lorsqu'il faut convaincre du bien-fondé de telle ou telle architecture cible. J'élabore pour cela des échelles qualitatives qui combinent 4 axes :

1. La réponse aux enjeux métier, en quantifiant le niveau de réponse à chaque enjeu majeur
2. La qualité intrinsèque de l'architecture, en termes de maintenabilité, d'évolutivité, de scalabilité, de performances, etc.
3. Les coûts de mise en œuvre que j'évalue soit par analogie avec des projets passés comparables, soit avec des abaques "grosse maille" que j'ai constitués par expérience.
4. Les risques liés à la mise en œuvre (ex : déficit de compétences, migration complexe, risque sur la continuité de service …)

 Le mix de qualitatif et quantitatif, à partir du moment où il est cohérent et bien expliqué, permet d'aligner tout le monde sur une analyse comparative. Les évaluations peuvent être challengées, mais pas la démarche qui permet de rentrer dans une dynamique de convergence constructive.

Pour conclure cette règle d'or, rien de mieux que la citation de William Edwards Deming, un éminent statisticien et conférencier américain :

"Sans données, on est juste une autre personne avec une opinion".

Pour ceux qui ont raté les précédents épisodes, voici les autres règles d'or publiées :

• Règle d'or #1 : le "pourquoi" tu n'oublieras pas
• Règle d'or #2 : la techno tu ne fuiras pas
• Règle d'or #3 : les points de vue tu aiguiseras
• Règle d'or #4 : la provocation tu utiliseras
• Règle d'or #5 : de diplomatie tu joueras
• Règle d'or #6 : une âme d'artiste tu auras