annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Les cadres d’architecture d’entreprise : un état de l’art

Cadres d'architecture d'entreprise.jpg
13810
0

Qu’est-ce qu’un cadre d’architecture d’entreprise ?

Un cadre d’architecture est la combinaison de quatre éléments principaux :

  • Un ensemble de cartes décrivant l’entreprise. De diverses natures - organigrammes, architecture de systèmes, modèles de données, modèles opérationnels, etc. - elles ont vocation à répondre aux questions essentielles : Qu’est-ce que cela fait ? Comment cela fonctionne-t-il ? A quoi, et à qui cela sert-il ? Chaque carte, chaque modèle est une réduction de la réalité.
  • Des modes d’emploi pour l’élaboration des différentes cartes. Il s’agit ici des méthodes de conception.
  • Des modes d’évaluation pour savoir où l’on en est. Les modèles de référence utilisés pour ces évaluations sont issus des « bonnes pratiques », des métriques et des modèles de maturité.
  • Des modes de fonctionnement pour faire « marcher » la gouvernance. L’objectif est d’impliquer les parties prenantes, de s’assurer des orientations prises, d’enregistrer les décisions, de maintenir les savoirs-faires, etc.

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 :

  • Les cadres à dominante conceptuelle : leur contenu est centré sur les concepts et méta-modèles (UAF, ArchiMate).
  • Les cadres à dominante méthodologique : leur contenu est centré sur les méthodes de conception et de conduite de l’activité d’architecture (TOGAF).
  • Les cadres à dominante référentielle : leur contenu est centré sur un domaine d’activité spécifique pour lequel ils fournissent des modèles de référence (ITIL, ACCORD, BIAN). Dans cet article nous ne traiterons pas de ce type de cadre d’architecture.

Le but reste de disposer de repères pour penser/évaluer/orienter les activités de l’entreprise.

A l’origine des cadres d’architecture d’entreprise

Le Zachman framework

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.

Le modèle Merise

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.

Le cadre SADT (Structured Analysis and Design)

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.

Les cadres d’architecture d’entreprise les plus utilisés aujourd’hui

TOGAF : cadre à dominance méthodologique

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.ADM.jpg

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.

ArchiMate : cadre à dominance conceptuelle

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 :

  • Une modélisation fondée essentiellement sur les diagrammes : l’heure est aujourd’hui à la visualisation dynamique des données (Data visualization).
  • Un formalisme « à plat » qui n’intègre pas de principe de contextualisation : un modèle ArchiMate est conçu comme un tout qu’il est difficile de partitionner en modules autonomes.
  • L’intégration du temps : la fameuse question « as is/to be » s’applique aux différentes couches de l’architecture. La couche « implementation & migration » d’ArchiMate n’y offre qu’une réponse limitée.
    Cadre conceptuel archimate.jpg

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.

UAF : cadre à dominance conceptuelle

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.

PEAF : cadre à dominance méthodologique

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.

 

PEAF.jpg

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).

Qu’en est-il aujourd’hui de la mise en œuvre des cadres d’architecture d’entreprise ?

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 :

 

“Enterprise Architecture is not a destination, Enterprise Architecture is not a journey, Enterprise Architecture is a way of travelling”

 

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).
Waterfall.jpg

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 ?

 

13810
0
Comment
MEGA

Qu’est-ce qu’un cadre d’architecture d’entreprise ?

Un cadre d’architecture est la combinaison de quatre éléments principaux :

  • Un ensemble de cartes décrivant l’entreprise. De diverses natures - organigrammes, architecture de systèmes, modèles de données, modèles opérationnels, etc. - elles ont vocation à répondre aux questions essentielles : Qu’est-ce que cela fait ? Comment cela fonctionne-t-il ? A quoi, et à qui cela sert-il ? Chaque carte, chaque modèle est une réduction de la réalité.
  • Des modes d’emploi pour l’élaboration des différentes cartes. Il s’agit ici des méthodes de conception.
  • Des modes d’évaluation pour savoir où l’on en est. Les modèles de référence utilisés pour ces évaluations sont issus des « bonnes pratiques », des métriques et des modèles de maturité.
  • Des modes de fonctionnement pour faire « marcher » la gouvernance. L’objectif est d’impliquer les parties prenantes, de s’assurer des orientations prises, d’enregistrer les décisions, de maintenir les savoirs-faires, etc.

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 :

  • Les cadres à dominante conceptuelle : leur contenu est centré sur les concepts et méta-modèles (UAF, ArchiMate).
  • Les cadres à dominante méthodologique : leur contenu est centré sur les méthodes de conception et de conduite de l’activité d’architecture (TOGAF).
  • Les cadres à dominante référentielle : leur contenu est centré sur un domaine d’activité spécifique pour lequel ils fournissent des modèles de référence (ITIL, ACCORD, BIAN). Dans cet article nous ne traiterons pas de ce type de cadre d’architecture.

Le but reste de disposer de repères pour penser/évaluer/orienter les activités de l’entreprise.

A l’origine des cadres d’architecture d’entreprise

Le Zachman framework

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.

Le modèle Merise

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.

Le cadre SADT (Structured Analysis and Design)

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.

Les cadres d’architecture d’entreprise les plus utilisés aujourd’hui

TOGAF : cadre à dominance méthodologique

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.ADM.jpg

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.

ArchiMate : cadre à dominance conceptuelle

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 :

  • Une modélisation fondée essentiellement sur les diagrammes : l’heure est aujourd’hui à la visualisation dynamique des données (Data visualization).
  • Un formalisme « à plat » qui n’intègre pas de principe de contextualisation : un modèle ArchiMate est conçu comme un tout qu’il est difficile de partitionner en modules autonomes.
  • L’intégration du temps : la fameuse question « as is/to be » s’applique aux différentes couches de l’architecture. La couche « implementation & migration » d’ArchiMate n’y offre qu’une réponse limitée.
    Cadre conceptuel archimate.jpg

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.

UAF : cadre à dominance conceptuelle

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.

PEAF : cadre à dominance méthodologique

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.

 

PEAF.jpg

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).

Qu’en est-il aujourd’hui de la mise en œuvre des cadres d’architecture d’entreprise ?

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 :

 

“Enterprise Architecture is not a destination, Enterprise Architecture is not a journey, Enterprise Architecture is a way of travelling”

 

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).
Waterfall.jpg

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 ?