mercredi 13 juillet 2016

Architecture de Systèmes ou Système d'Architectures

Un château de cartes méthodologique


Visions ensemblistes, systémiques, démarches de modélisation se sont formalisées au cours des décennies de la courte histoire de l'informatique.

Elles sont à présent matures, et largement enseignées au niveau académique : modélisation des données, des processus, multiples langages formels dans la famille UML, métiers de l'analyse de systèmes, de l'amélioration des processus, ...

De sorte que plusieurs disciplines sont progressivement apparues. Chacune se réfère à ses propres standards, ses propres prescriptions, ses cursus, ses certifications.

Cependant, avec la révolution numérique qui est en cours, avec le séisme technologique amorcé, tous ces édifices de savoir et de certitudes sont ébranlés. Au sommet du "château de cartes" méthodologique, se trouve l'Architecture d'Entreprise, et nous avons ici argumenté pour sa refondation. Le doute atteint maintenant jusqu'à un expert de l'Open Group, organisme promoteur du Togaf, dont le corpus méthodologique est colossal.

Dans ce contexte, face à un projet de système, comment procéder ? Doit-on imaginer une cible ? La concevoir comme un tout cohérent, application d'un système de modèles ? Ou juxtaposer différents modèles ?

Parmi toutes ces approches, la plus tendancielle est celle qui juxtapose autant de modèles qu'il y a de disciplines. On peut la qualifier "Système d'Architectures" : elle combine Architecture des SI, Architecture métier, Architecture fonctionnelle, Architecture Technique...et tous ces termes coexistent.

"Système d'Architectures" : complexité, risques et sur-coûts


Toutes ces disciplines consacrent autant de visions partielles du "système". Elles s'écartent de la réalité de la vraie vie qui mixe processus, savoir-faire humains, logiciels, données, "apps", ...

La juxtaposition de ces différentes architectures crée de la complexité, car la symbiose entre les architectures est traitée a posteriori. Sans vision ensembliste, chacun des métiers d'architecture voit midi à sa porte. Doit-on concevoir d'abord les processus, les automatiser, et leur asservir les fonctions ? Ou, à l'opposé, faire table rase des processus, dans un enchaînement automatique de fonctions ? Ou encore, figer l'organisation pour y couler les exigences en système d'information ? Une combinatoire de détails de cohérence, aux multiples paramètres, conciliés au cas par cas.

La démarche "système d'Architectures" est risquée, car elle ne met pas le système d'ensemble à l'abri des surprises, dans le détail des interactions entre architectures. Au final, les multiples aléas, même improbables, en se combinant, génèrent retards et sur-coûts.

Pourtant, cette approche semble cumuler les précautions, les savoirs, la sécurité des certifications, et autres préconisations émises par toutes les fées disciplinaires (ISACA, Open Group, OMG, ISO,...). Mais c'est un faux semblant. Ce capharnaüm méthodologique ne garantit pas le succès, au contraire les projets sont pour une bonne part en échec, comme nous l'avons déjà remarqué ici.



La promesse de l'Architecture de Systèmes



L'idéal serait de concevoir une Architecture d'ensemble, une Architecture de Systèmes, qui puisse prendre en compte tout le système, dans sa complexité, et toutes ses facettes au delà de la seule vision "informatique".

C'est un défi de conception, un idéal, au quel veulent répondre, dans notre pays, au moins deux "Centres d'Excellence" en Architecture et systèmes complexes : CESAMES, et CEISAR. L' ambition de l'Architecture de Systèmes complexes est en effet immense. La promesse a une portée universelle.

Cependant cette excellence se traduit, dans chaque cas, par un "modèle" du "système" pris dans sa globalité. L'approche est logique, rigoureuse, sans doute "excellente", car présentée comme issue d'une certitude scientifique.

L'objet n'est pas ici de critiquer ces méthodes et leurs modèles. Elles sont cohérentes et remarquables. Simplement, leur axiome de base est qu'une telle maîtrise globale, dans un modèle homogène, est possible. Cet axiome est malheureusement totalement déconnecté de la réalité des actuels projets de systèmes d'information, dans un contexte secoué par une tempête d'incertitudes..

En effet, en pratique, dans l'exercice de l'Architecture d'Entreprise, le cas de la conception d'un nouveau système à partir de zéro ne se pose jamais :

  • il y a la plupart du temps un existant, incontournable pour assurer la continuité du service, existant qui ne peut respecter les canons du modèle,
  • même si le système est entièrement neuf, il est irréaliste d'ignorer les multiples composants logiciel, ou ERP, ou services, utilisables,
  • enfin, le problème ne se réduit pas à la création du futur système, il faut aussi en assurer la montée en puissance, et la conduite du changement, phases transitoires cruciales qui ne rentrent pas non plus dans le modèle.

Ces contraintes pratiques, ignorées par l'axiomatique de l'Architecture de Systèmes, annulent la portée d'une vision conceptuelle pourtant remarquable.


L'illusion des modèles


Tous les grands cabinets, gourous et grands prophètes de notre époque, nous abreuvent de constats et de prévisions sur les ruptures historiques. L'époque change. mais ces mêmes prophètes nous prescrivent les outils du passé.

Le dénominateur commun des recettes miracle, mentionnées ci-dessus, passe par des modèles, des plans d'ingénierie représentant ce monde futur. Une illusion de maîtrise d'une réalité infiniment complexe.

Le modèle est, en soi, utile, praticable dans un cas simple : celui d'un ensemble d'information cerné, stable, non ambiguë, de processus invariants, d'interactions habituelles, d'une industrie opérationnelle, de procédures réglementées, ... Mais dans un système plus vaste, et en transformation, la dynamique imprévisible multiplie les aléas, et rend tout plan obsolète le lendemain de sa création.

Car on applique la recette miracle du modèle à un champ infini, insaisissable, où le recours à cet artifice est totalement illusoire.

Doit-on pour autant se passer de tout effort de conception, de tout modèle, de toute exigence de qualité, par exemple en absorbant toute donnée disponible et la déposant sans détour dans un Data Lake ? Ceci serait une autre illusion, sacrifiant à la mode du Big Data, passant d'un excès à l'autre.

Une modélisation minimaliste du cœur de l'Architecture


Arrêtons ces illusions, levons le malentendu : l'enjeux est simplement d'appliquer l'effort de conception, et une modélisation minimaliste, sur la clé de voûte de l'Architecture, sans se perdre dans la mouvance de tout le système et ses infinies variantes.

Voilà bien le changement de paradigme de l'Architecture Flexible, une Architecture "tolérante" avec toutes les solutions, tous les existants. mais une Architecture exigeante pour le périmètre très restreint de sa clé de voûte, de sa pierre angulaire, le cœur de l'Architecture d'ensemble. Ce cœur est constitué par un système d'intégration taillé sur mesure. Un système conçu pour intégrer et donner toutes les flexibilités, comme cela a été précédemment exposé sur ce blog. Un système basé sur un modèle réduit et stable, reprenant les invariants de chaînes de valeur.

Ainsi cette Architecture minimaliste devient-elle pragmatique, réaliste, et opérante, parce que son périmètre est réduit à l'essentiel, et ignore le subsidiaire.


samedi 2 juillet 2016

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