annuler
Affichage des résultats de 
Afficher  uniquement  | Rechercher plutôt 
Vouliez-vous dire : 
alonjon
MEGA
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 ?

 

6 Commentaires
Billy Händel
Non applicable

Très bonne article , la mise en œuvre de ses cadres d'architecture dépend-elle de la taille de l'entreprise ?  Et une autre question ? Appliquer une partie du cadre d'architecture revient d'elle à appliquer le cadre d'architecture ?

 

alonjon
MEGA
MEGA

De même que les plans d'une maison n'ont pas les mêmes exigences de ceux d'un gratte-ciel, la taille de l'entreprise détermine votre "besoin" en architecture,  
L'OpenGroup a publié un guide pratique pour les architectures digitales (Digital Practitioner Body of Knowledge: https://publications.opengroup.org/c196) dans lequel Charles Betz y développe une pratique de l'architecture qui va de l'entreprise individuelle (Individual/Founder) à celle pratiquée dans un grand groupe (enduring enterprise).
Ceci correspond bien à votre intuition.

 

Franck_CSOLAL
Senior Member

En prenant du recul sur l'application des cadres d'architecture d'entreprise et leur mise en perspectives, l'article est intéressant.

Je m'attendais cependant à retrouver les classiques notions de principes d'architecture et la référence à la démarche d'urbanisation à la Française. Mais en arrivant à la fin de l'article, j'ai deviné que toutes ces grosses machines étaient remises en cause.
Je ne renonce pas tout de suite à l'application d'un tel cadre d'architecture (il faudrait au moins essayer puisque chaque contexte d'entreprise est différent). N'y a-t-il pas un juste milieu entre approche traditionnelle de l'architecture et architecture de rupture (voire disparition de cadre) ?

alonjon
MEGA
MEGA

Merci pour votre commentaire. Il permet d'anticiper sur les articles à suivre.
L'activité d'architecture est et restera. Les principes de modularité et d'autonomie, orientés selon des finalités partagées ne vont pas disparaitre demain. Comme le notait Jacques Printz, « l'architecture sans expérience, c'est de pure théorie, Le développement sans architecture, c'est du bricolage ».

Il y aura donc toujours des cadres d'architecture. Mais lesquels ?
Ce qui est principalement en cause est l'intégration de l'activité l'architecture dans les activités de l'entreprise. L'accélération des changements fait apparaitre en creux la "boucle étrange" qui existe entre la carte et le territoire, entre le modèle et le phénomène modélisé. Le cycle long qui permettait aux grosses machines d'enchaîner sagement architecture, développement et opérations est derrière nous. La complexité des systèmes actuels rend d'ailleurs ce cycle impossible.
Le défi est dans l’établissement dynamique de la juste maille d’autonomie et de pilotage. C’est bien un travail d’architecture ... à l’échelle de l’entreprise.

Jean-Luc Garnier
Non applicable

Je vois ici une ambiguïté que je retrouve souvent quand il s'agit de parler en français de "Enterprise Architecture". Dans le sens original du terme, il est question de l'Architecture d'une entité d'intérêt, avec la vision de l'entreprise.

Le fait que l'entreprise soit l'entité d'intérêt est un cas particulier.

De ce fait, les points de vue d'architecture (opérationnels, système, techniques, programmatiques, activités, informationnels ou autre) porte sur l'entité d'intérêt, évidemment ; mais le but est ici d'exprimer la valeur pour l'entreprise en regard de sa mission et de ses objectifs ("Enterprise Goal" ne doit pas être confondu avec le but de de l'entité d'intérêt qui a aussi des buts et une utilité).

Cette distinction entre "Business" (centré sur la valeur pour l'entreprise) est de ce fait à distinguer de "Operational" (centré sur la valeur pour l'utilisateur et l'acquéreur de l'entité d'intérêt)

Note : il est question, dans cet article,  de cadre d'architecture comme ArchiMate, UAF, TOGAF et Zachman, qui ne font pas trop cette distinction. J'invite à regarder des cadres comme NATO Architecture Framework (NAF), plus explicites sur le sujet.

J'espère que ces quelques mots vous inciteront à faire des activités d' "Enterprise Architecting" pour un Système, un services, un produit, une lignes de produits, etc.

Note:  Pour donner quelques références derrière mes propos, je suis "Project Editor" des standards ISO/IEC/IEEE 42010 (Architecture Description) et ISO/IEC/IEEE 42020 (Architecture Processes) ; par ailleurs, co-auteur du NATO Architecture Framework (NAF) et relecteur officiel du cadre Unified Architecture Framework (UAF).

alonjon
MEGA
MEGA

Jean-Luc,
Merci pour ce commentaire et la distinction à faire entre l'architecture de l'entreprise et l'architecture des systèmes de l'entreprise.

L’article se situe plus volontiers sur le système d’intérêt « entreprise » que sur les systèmes de l’entreprise. A ce titre, les activités d'architecting engagent l’ensemble de l’architecture d’entreprise, depuis la mise en perspective des missions de l'entreprise. la définition de ses produits, jusqu'à ses modes de fonctionnement.
A l'occasion, le besoin de préciser la portés des activités d' "Enterprise Architecting" selon que l'on s'intéresse à un système, un service, un produit, une ligne de produits, soulève la délicate question de la définition de « produit ». 
Cela fera l'objet de futures publications sur ce blog.

contributeurs