La rigidité est la norme, la flexibilité l'exception

Sur ce site, nous avons à plusieurs reprises vanté les avantages de l'Architecture Flexible.
Plus récemment, dès lors que l'émergence d'une architecture du SI réellement flexible est acquise, ce qui commence à être admis, nous avons proposé de conduire les projets SI de façon flexible, ...C'est le concept de "Projet Flexible".

En somme, une approche pour affronter les défis de complexité des projets, un fil pour dévider la pelote de laine.

Le fil pour dénouer la complexité

Cela découle d'une réflexion simple :

• la flexibilité de l'Architecture est précieuse : elle rend celle-ci plus durable, en permettant les adaptations aux évolutions qui s'imposeront, sur tous les plans, du Business, aux processus, aux fonctions du SI, et à l'architecture technologique,
• mais cette flexibilité est aussi un atout pour le Projet, en permettant une approche progressive, sans Big Bang, ménageant des phases d'appropriation avec leur propre rythme. Un projet où chaque étape est validation concrète, grâce à la création de l'Architecture dès le début du projet.

La durée de vie du système sera accrue, et sa gestation mieux contrôlée car progressive et adaptative.

On pourrait croire que cet usage récurrent du mot "flexible" sacrifie à la mode de l'agilité... et que cela n'est que paroles !

La rigidité est naturelle

De fait, il ne suffit pas de dire "flexibilité". Au contraire, la flexibilité doit être voulue : la rigidité est la norme, elle se crée naturellement sans effort.

Rigidité de l'architecture

Prenons le cas de l'Architecture du SI. Le plus souvent on dressera un magnifique schéma rationnel qui sous-tend le futur système... On créera une vision cible, un partage du territoire fonctionnel, des quartiers, des zones, bref un classement sensé être immuable : n'est-ce pas déjà rigidité ?

On adossera cette architecture dite "fonctionnelle" sur une architecture des données. Par exemple, du temps de la période de la modélisation à tout propos, symbolisée par le langage universel de modélisation (UML), le modèle dominant pour les données est le modèle relationnel. Dès lors que ce modèle, adapté aux besoins des systèmes opérationnels, ne permet pas de multiplier les axes d'analyse pour les besoins décisionnels, on invente de nouveaux modèles, et on organise les norias de données entre les SI opérationnels et les SI de la Business Intelligence.

Le résultat de cette histoire prend la forme de silos de données opérationnelles, plus ou moins cloisonnés, partageant les données de référence avec plus ou moins de bonheur par rapport aux canons de beauté de la gestion des référentiels de donnée (Master Data Management). Et la Business Intelligence, un peu plus transversale, n'en est pas moins balkanisée en ODS, Datamart ...

Bien sûr, ces territoires de systèmes perdurent encore, et sont progressivement institutionnalisés par la Gouvernance. Celle-ci, partant de bons principes, génère aussi sa propre rigidité : compromis créés à force de frictions internes, inertie structurelle, modes d'organisation surannés, empilements hiérarchiques, se cristallisent en tables de lois, frontières inamovibles.

L'histoire de ces rigidités héritées ne s'arrête pas à la porte de notre époque, nous y contribuons encore :

• de nouvelles exigences de transversalité apparaissent, par exemple avec la réglementation sur les données personnelles, et sur l'Open Data : il faut à nouveau dédier une "architecture" spécifique, maillée avec celle du "Legacy".
• la possibilité d'exploiter des masses considérables de données accumulées en interne (les "logs") ou externe (réseaux sociaux...) crée de nouveaux territoires de "Big Data", nouvelle province, en ajout à l'existant, et faiblement intégrée à cet ancien monde.

Bien sûr, à chaque étape, ses progrès : en puissance d'analyse sur un monde infini de données, en agilité de développement, en chute vertigineuse des coûts matériels, en flexibilité des solutions, au recours extensif à l'Open Source, à l'économie collaborative.

Des ruptures tonitruantes, mais aussi des révolutions silencieuses. Par exemple, réaliser, sans entrer dans les affres du Big Data et de l'explosion de ses multiples déclinaisons, sans détour, sans data scientist, et en "libre service" : des visions de données simples, pour des tableaux de bord, des indicateurs,  des tableaux croisés dynamiques, sur tout type de jeu de données.

Sur ce chemin s'écrira immanquablement une histoire de déconvenues, de choix malheureux de tel ou tel plateforme reléguée par une vente au plus offrant, par les aléas de toutes sortes, ... Ces scories seront durables. Qui se souvient du système "Pick" qui avait tout pour plaire, avec sa base flexible et son langage d'interrogation "naturel" ? Et combien de conversions vers Unix, quand le produit fut passé de mode ? Pourtant, dans l'univers de la fondation Apache resurgissent des principes proches, et le présent bouillon de culture aura aussi ses laissés pour compte.

L'Architecture résulte toujours d'une histoire, en partie subie, et ses contraintes globales, ses rigidités fondamentales, s'imposent naturellement.

Rigidité des projets

Certes, à notre époque, on sait mener des développements en mode agile. certes on sait travailler en mode collaboratif, mener des "hackathon" pour mettre des équipes créatives en compétition.

Mais soyons réalistes :

• peut-on mener toutes les transformations selon ces recettes ?
• et, en pratique, la culture d'entreprise, les pratiques, les méthodologies, le management, la gouvernance vont-ils dans ce sens de l'agilité ?

Prenons simplement un axe d'analyse, parmi tant d'autres relevant de la sociologie des organisations : les prescriptions méthodologiques. C'est un thème mainte fois développé ici au sujet de l'Architecture d'Entreprise, et un sujet d'étonnement : comment peut-on raisonnablement croire que la "certification" d'architectes d'entreprise apporte une quelconque sécurité de conception des SI à notre époque !

Qu'en est-il de la méthodologie de projet ? D'abord le volet "gouvernance" avec l'institution de la dichotomie "maître d'ouvrage" et "maître d'oeuvre". Certes dans un projet complexe, il y a une dimension métier et une dimension SI. Mais doit-on être aussi rigide dans cette dialectique ?

Puis il en va bien sûr de la une gestion de projet, basée sur une méthode. En soit, la méthode n'est pas mauvaise, elle procède de bonnes intentions de gestion, de prévision, d'optimisation. Mais, la méthode, qui sécurise les acteurs, renforce la tradition : les exemples d'application de la méthode sont ceux de projets classiques, menés en mode "rigide", avec une prévision rationnelle, un ordonnancement cohérent... mais on en connait les extraordinaires contre-performances, comme nous l'avons pointé dans le message précédent.

Pire, dans un contexte naturellement conservateur, tout promoteur de changement a la charge de la preuve, et ne sera pas reconnu en cas de succès. Mais celui qui ne prend aucun risque, en respectant la tradition, n'aura pas la responsabilité de l'échec : l'échec est collectif (cf. la gouvernance par consensus et compromis), et, bien souvent, le projet a été porté par le "drapeau" d'un grand cabinet. Ainsi la rigidité du concept, le paradigme projet perdure.

Bref, la rigidité est la norme, et la flexibilité l'exception.

"Penser" la flexibilité 

Revenons au propos initial : la flexibilité n'est pas un sujet trivial, on aurait tors de rester au niveau du discours.

La flexibilité doit être voulue, pensée, méritée :

• flexibilité de l'Architecture, dont nous avons exploré les différentes dimensions, et pour les quelles les données sont des leviers,
• flexibilité du Projet, pour en réduire les risques, et maximiser l'apport de valeur au plus tôt.

Une flexibilité globale, qui n'est pas de l'ordre du détail, mais concerne les grands composants, les chantiers majeurs.

L'ingénierie de la flexibilité est émergente.

Nous devons la décliner sur 2 plans distincts, celui de l'Architecture, avec ses figures de style, et celui des projets avec leurs scénarios de maîtrise des aléas.

Trouver l'équilibre au plus haut