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.
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 :
Ces contraintes pratiques, ignorées par l'axiomatique de l'Architecture de Systèmes, annulent la portée d'une vision conceptuelle pourtant remarquable.
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.
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.
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.
