Un cadre d’architecture est la combinaison de quatre éléments principaux :
Un cadre d’architecture peut être général comme TOGAF (The Open Group Architecture Framework, TOGAF ) ou spécifique à un domaine d’activité comme COBIT (Control Objectives for Information and related Technology).
Chaque cadre met plus au moins l’accent sur l’un des aspects évoqués ci-dessus. On peut ainsi distinguer :
Le but reste de disposer de repères pour penser/évaluer/orienter les activités de l’entreprise.
Le pionnier en matière de cadre d’architecture d’entreprise est John Zackman, qui en 1987, lorsqu’il travaillait encore à ****, a créé le « Zachman framework ». En réalité, il s’agit plus d’une taxonomie que d’un cadre d’architecture d’entreprise.
Il s’organise selon les six grandes questions : Quoi (What), Comment (How), Où (Where), Qui (Who), Quand (When), Pourquoi (Why). Chacune de ces questions est déclinée sur différents niveaux d’abstraction de l’entreprise, depuis les objets sur le terrain jusqu’aux concepts généraux.
Cependant les tentatives du cadre Zachman1 à proposer un modèle conceptuel rigoureux n’ont connu qu’un succès limité. La raison principale est que l’approche systémique se laisse mal enfermer dans les « six interrogatives ». L’approche centrée sur les agents se trouve à l’étroit dans la question « Qui » de Zachman, et ceci tout particulièrement à l’heure de l’intégration homme/machine et de l’intelligence artificielle. Quant à l’approche capacitaire, elle ne trouve pas vraiment sa place dans la notion de fonction (How). Enfin, d’autres dimensions contemporaines comme l’expérience client sont absentes du cadre.
Le « Zachman Framework » n’est aujourd’hui guère référencé dans les cadres d’architecture les plus utilisés.
Dans les années 1975 à 1990, en France, le modèle Merise a constitué un formidable élan dans l’accompagnement de l’informatisation des entreprises. Merise est un cadre complet sur le plan conceptuel et méthodologique.
Le cadre propose une étude des systèmes selon trois axes : communication, données, traitements. Ces axes sont eux-mêmes déclinés sur quatre niveaux d’abstraction, qui forment le support de l’approche méthodologique : conceptuel, organisationnel, logique et physique.
Mis à mal par l’avènement des méthodes orientées objets et du langage UML de l’Object Management Group (OMG), le modèle Merise est aujourd’hui très largement marginalisé, et ceci d’autant plus que l’informatisation des entreprises a laissé place aux progiciels.
Pendant de Merise dans les pays anglo-saxon, le cadre SADT a connu une aventure similaire. Associé à la famille de langage de modélisation IDEF (Integration Definition for Function Modeling), SADT a été largement adopté aux Etats-Unis grâce au département de la défense (DoD).
D’un périmètre moins large que Merise, SADT est centré sur l’analyse des systèmes complexes par décomposition fonctionnelle, du général au particulier. Son concept central est celui de « fonction » que l’on retrouve dans l’ingénierie des systèmes.
Comme le modèle Merise, le cadre SADT a été marginalisé par l’avènement des méthodes orientées objet et du langage UML.
Dans le domaine des cadres à dominance méthodologique, le cadre le plus connu et utilisé est celui de The Open Group : TOGAF (The Open Group Architecture Framework). La fameuse roue de la méthode ADM (Architecture Development Method) en est quasiment devenue la signature. Elle correspond aux grandes phases de transformation de l’entreprise.
Figure 1 – La roue ADM de TOGAF
TOGAF comprend aussi un cadre conceptuel : le Content Meta-Model2. Ce dernier, peu formel, a pour vocation principale d’expliciter les livrables des phases de la méthode ADM.
En complément du Content Meta-Model, The Open Group a développé le cadre ArchiMate qui est principalement un cadre conceptuel. Son formalisme simplifié, inspiré du langage UML, fait de lui une sorte de Merise contemporain, dont il partage dans les grandes lignes la couverture fonctionnelle. On y retrouve une analyse des systèmes selon quatre axes (appelés aspects) : Passive Structure, Behavior (les traitements), Active Structure (les agents), Motivation. Le cadre ArchiMate étant également postérieur à l’événement de l’orientée objet, il intègre certaines notions héritées du langage UML.
Cependant il bute sur d’autres limites rencontrées dans l’exercice de Merise :
Figure 2 – Le cadre conceptuel ArchiMate
Le cadre ArchiMate comporte ainsi les faiblesses de ses atouts : il propose un modèle léger et simplifié permettant des cartographies rapides, utiles pour un premier défrichage du domaine étudié. Au long court, ces cartes globales s'avèrent difficiles à faire évoluer. Comme dans le modèle Merise, il lui manque une approche modulaire pour traiter les enjeux de l’agilité à l’échelle. Ce manque provient des limites du modèle Entité/Relation (E/R) qui leur sert de fondation.
A ce titre le cadre UAF (Unified Architecture Framework) de l’OMG dispose de fondations conceptuelles plus avancées, issues des besoins combinés de l’ingénierie système et de l’architecture des systèmes complexes à l’échelle de l’entreprise. Développé à l’origine pour les besoins de l’industrie de la défense, UAF couvre désormais l’ensemble des dimensions de l’architecture d’entreprise. Il dispose d’une intégration naturelle avec la stratégie (BMM3), la modélisation des processus (BPMN4), l’architecture logicielle avec UML5 et l’architecture des systèmes avec SysML6.
En outre UAF intègre dans ses fondations les notions de contextualisation et de temps. La richesse d’UAF s’accompagne d’une plus grande complexité et nécessite un outillage plus performant pour être pleinement exploitée.
Sur le plan méthodologique, le cadre PEAF (Pragmatic Enterprise Architecture Framework) compléte utilement TOGAF par l’addition d’une approche du changement à différentes échelles (Strategy, Business Planning, Business Change, IT Change), l’usage de modèles structurés et la mise à disposition d’un modèle de maturité de la pratique d’architecture dans l’entreprise.
On y retrouve également les phases de l’ADM sous la forme « Prepare, Implement, Operate ». Le Content MetaModel est désigné par la boîte « Model » et adresse en outre la question des outils.
Figure 3 – PEAF : Pragmatique Enterprise Architecture Framework
La confrontation de TOGAF et de PEAF illustre le fait qu’il n’existe pas de cadre universel, bien que l’on y retrouve dans chacun les grands invariants que nous avons mentionnés en introduction (cartes/modèles, méthodes de conception, mode d’évaluation, mode de fonctionnement).
En termes de mise en œuvre, très peu d’entreprises déploient un cadre d’architecture dans son intégralité. Chaque cadre, en effet, vise une forme de complétude et d’exhaustivité qu’il serait à la fois coûteux et stérile de suivre à la lettre.
C’est pourquoi la plupart des entreprises décident d’adapter les cadres d’architecture en fonction de leurs besoins. Elles limitent leur utilisation sur un certain périmètre d’activités pour en tirer un maximum de valeur ajoutée. Elles considèrent ces derniers comme un ensemble de lignes directrices et non comme un manuel rigoureux de normes et de pratiques.
Une formule de Pragmatic EA résume bien cet état d’esprit :
C’est bien en effet sur la manière de faire de l’architecture – le « way of travelling » – que des changements majeurs s’opèrent aujourd’hui. La prévalence des approches agiles perturbe les dispositifs traditionnels d’architecture d’entreprise. Ces derniers sont les héritiers de méthodes qualifiées aujourd’hui de « waterfall ». Le « sens de l’étude » indiqué ci-dessous dans la méthode Merise en porte la marque : on démarre du conceptuel (C) pour arriver au physique (P) avec peu de retours arrière (peu d’itérations).
Figure 4 – La méthode « waterfall » de Merise 7
Deux piliers centraux aux cadres d’architecture traditionnels sont aujourd’hui ébranlés : la notion d’exigence et celle de projet. Tous deux sont au cœur de l’ADM de TOGAF.
Est-ce dire qu’il n’y a plus de projets ? Bien sûr que non. Mais ce n’est plus par les projets que se rythme la transformation des entreprises. Ce sont les notions de produits, features et backlogs qui forment le cœur du continuous delivery. L’expression de besoins, quant à elle, intègre l’expérience client avec les notions de parcours clients et de « job-to-be-done ».
Subrepticement, ces changements affectent en profondeur les cadres conceptuels. Ils doivent répondre à des exigences de modularités auxquels les anciens méta-modèles ne sont pas préparés. Pour supporter les changements en continue, il faut en effet pouvoir faire de l’architecture en continue. Agilité et adaptation riment avec modularité.
Les pratiques, méthodes et outils d’architecture ont ainsi de nombreux défis à relever. Est-ce bien de tels bouleversements que vous observez dans votre pratique des cadres d’architecture ?
1 Notament les tentatives en 1990, avec Samuel B. Holcman et Le Zachman Institute for Framework Advancement et celle de 2012 avec le rachat du FEAC Institute.
2 Le Content MetaModel de TOGAF: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html
3 BMM: Business Motivation Model. Une spécification de l’OMG: https://www.omg.org/spec/BMM/
4 BPMN : Business Process Model & Notation, une spécification de l’OMG: https://www.omg.org/spec/BPMN/2.0.1/
5 UML: Unified Modeling Langage, une spécification de l’OMG : https://www.omg.org/spec/UML/ISO/19505-2/PDF
6 SysML: System Modeling Language, une specification de l’OMG: https://www.omg.org/spec/SysML/
7 Source Michel Diviné – Parlez-vous Merise ?