La démarche architecture, sans aucun doute nécessaire puisqu’il s’agit de donner l’importance qu’elle mérite à la conception des systèmes et des applications, pose le problème des moyens de formalisation nécessaires.

Au niveau architecture d’entreprise, des démarches telles que Zachman ou TOGAF (pour ne citer qu’elles) se sont révélées trop lourdes à mettre en oeuvre et conduisent à une paperasserie surabondante et donc mal exploitée. Dans un début leurs délivrables ont sans doute rassuré les managers en quête de visibilité sur leurs systèmes d’information, et sur leur alignement avec les objectifs métiers de l’entreprise … avant de les inquiéter sur le coût et le bénéfice opérationnel réel de ces opérations.

Au niveau applications, le document d’architecture, souvent trop livresque et d’une utilité limitée pour les développeurs eux-mêmes, souffre sans doute des mêmes défauts. Long et coûteux à établir, peut-être mal adapté à des systèmes distribués, souvent trop imprécis et incomplet, le SAD est-il une réponse adéquate aux questions suivantes :
– l’application décrite s’inscrit-elle bien dans son éco-système, au niveau technologique (pas de nouvelles technologies non justifiées, utilisation des moyens d’intégration disponibles, …) et au niveau logique (récupération de données et traitements existants)?
– le document est-il suffisamment prescriptif du point de vue de l’architecture elle-même? ne laisse-t-il pas trop de liberté d’interprétation aux développeurs?
– le niveau de détail des descriptions est-il compatible avec les attentes des développeurs (modèle de données, décomposition en modules, cinématique des modules, communications entre les modules, paramétrisation, …)?
– à supposer que l’architecte ait lui-même une maîtrise suffisante de UML et l’ait utilisé dans son document, les développeurs sont-ils eux-mêmes à un niveau de connaissance suffisant de ce formalisme?
– le SAD, s’il est pertinent pour décrire l’architecture d’une application, est-il pertinent pour décrire un système, en particulier distribué?
– le coût du SAD n’est-il pas élevé en regard des avantages réels qu’il procure en termes d’objectifs qualité?

Des alternatives récentes ont vu le jour, à mi-chemin entre l’architecture d’entreprise et l’architecture d’applications, comme la méthode pubique Praxeme dans l’Hexagone, qui réduit le nombre de dimensions en comparaison avec le framework de Zachman, et privilégie des représentations schématiques. Elle a aussi ses propres défauts : un nouveau vocabulaire, assez hermétique aux informaticiens de formation, un nouveau d’abstraction quelquefois trop élévé, …

Du côté anglo-saxon, RM-ODP, très orienté éveloppement distribué et s’appuyant autant que possible sur un langage formel, nous semble mériter l’attention.

RM-ODP a quatre caractéristiques fondamentales :
– une approche orientée objet pour la spécification de systèmes;
– la spécification d’un système sous la forme de perspectives différentes mais reliées;
– la prise en compte spécifique de la problématique de la distribution (il faut la rendre transparente pour les applications – notion de couplage lâche);
– un framework pour évaluer la conformité du système (respects de standards).

RM-ODP est peut-être à considérer comme une source d’inspiration pour faire évoluer/améliorer notre SAD.