THOT ITArchiMate 3.2 vs 4.0
Analyse détaillée des différences entre ArchiMate 3.2 et ArchiMate 4.0 : nouveaux éléments, domaine Physique, règles de relations et conformité.
ArchiMate 4.0, publié par The Open Group en 2024, est la première version majeure depuis ArchiMate 3.0 (2016). Les évolutions sont ciblées : elles n'inversent pas la logique du langage mais comblent des lacunes identifiées par les praticiens sur plusieurs années d'usage.
Cette page compare ArchiMate 3.2 (dernière révision mineure de la série 3) et 4.0 sur chaque point d'évolution.
Vue d'ensemble des changements
| Domaine de changement | ArchiMate 3.2 | ArchiMate 4.0 |
|---|---|---|
| Couche Physique | Éléments intégrés au domaine Technologie | Couche indépendante à part entière |
| Value Object | Absent | Nouvel élément dans le domaine Motivation |
| Capability Realization | Absent (relation implicite) | Élément formel dans le domaine Stratégie |
| Éléments Physiques | Facility, Equipment, etc. rattachés à Technology | Rattachés à la couche Physical distincte |
| Règles de dérivation | Tables partiellement définies | Tables normatives complètes et révisées |
| Niveaux de conformité | Deux niveaux (conforme / non conforme) | Trois niveaux explicites |
| Sémantique des junctions | AND/OR junction, règles implicites | Sémantique AND/OR clarifiée et normée |
1. La couche Physique : de rattachée à indépendante
C'est le changement structurel le plus visible de la version 4.0.
En 3.2
Les éléments physiques (Facility, Equipment, Distribution Network, Material) existaient déjà depuis ArchiMate 3.0, mais ils étaient rattachés au domaine Technologie. Un data center, une usine et un serveur étaient conceptuellement dans la même couche, ce qui créait une ambiguïté entre l'IT et le monde physique non informatique.
En 4.0
Le domaine Physical devient une couche indépendante, positionnée en dessous de la couche Technologie dans le cadre du langage. La distinction est désormais normative :
| Couche | Périmètre |
|---|---|
| Technology | Infrastructure informatique : serveurs, OS, réseau, middleware |
| Physical | Infrastructure matérielle non informatique : bâtiments, machines industrielles, convoyeurs, matières premières |
Pourquoi ce changement ?
Les usages industrie 4.0, IoT et convergence OT/IT avaient mis en évidence le besoin de modéliser des systèmes cyber-physiques sans mélanger les couches IT et physique. La séparation en 4.0 permet de représenter des architectures industrielles sans ambiguïté.
Éléments concernés
| Élément | En 3.2 | En 4.0 |
|---|---|---|
Facility | Domaine Technologie | Domaine Physical |
Equipment | Domaine Technologie | Domaine Physical |
Distribution Network | Domaine Technologie | Domaine Physical |
Material | Domaine Technologie | Domaine Physical |
Physical Function | Domaine Technologie | Domaine Physical |
Physical Process | Domaine Technologie | Domaine Physical |
Physical Service | Domaine Technologie | Domaine Physical |
Impact sur les modèles existants
Les modèles 3.2 utilisant ces éléments dans le domaine Technologie restent valides sémantiquement, mais un outil conforme à 4.0 les classera désormais dans la couche Physical. La migration consiste principalement à requalifier le rattachement de couche sans modifier la sémantique des éléments.
2. Nouveaux éléments dans le domaine Motivation
Value Object — nouveau en 4.0
En 3.2, le domaine Motivation contenait l'élément Value pour exprimer la valeur perçue par les parties prenantes. Cet élément était intentionnellement abstrait.
En 4.0, Value Object est ajouté pour représenter une valeur concrète et échangeable entre acteurs :
| Élément | Nature | Exemple |
|---|---|---|
Value (3.2 et 4.0) | Abstrait — valeur perçue | « Réduction des coûts opérationnels » |
Value Object (4.0 uniquement) | Concret — objet porteur de valeur échangé | Un bon de commande, un rapport, une licence |
Lien avec la Value Stream
Value Object est conçu pour être utilisé conjointement avec Value Stream (domaine Stratégie) : chaque étape de la Value Stream transforme ou transfère un Value Object. Cette combinaison permet de tracer la création de valeur de bout en bout.
3. Nouveaux éléments dans le domaine Stratégie
Capability Realization — nouveau en 4.0
En 3.2, le lien entre une Capability et les éléments concrets qui la réalisent (processus, applications, infrastructure) était exprimé via des relations de Réalisation directes, ce qui rendait difficile la traçabilité fine dans les grandes architectures.
En 4.0, Capability Realization est un élément intermédiaire formel qui porte ce lien et peut être associé à plusieurs éléments d'implémentation de couches différentes, ainsi qu'à un Plateau dans le domaine Implémentation & Migration pour planifier l'acquisition progressive de capacités.
Cas d'usage : feuille de route de capacités
En 4.0, on peut modéliser « la capacité X sera partiellement réalisée au Plateau 2 (via l'application Y) et complètement au Plateau 3 (avec l'infrastructure Z) » de façon formelle et sans ambiguïté.
4. Révision des règles de relations et de dérivation
En 3.2
Les tables de relations autorisées entre types d'éléments étaient définies mais incomplètes, notamment pour les relations inter-domaines. Les praticiens rencontraient des cas non couverts, obligeant à des interprétations.
En 4.0
Les tables normatives sont révisées, complétées et intègrent les nouveaux éléments (domaine Physical, Value Object, Capability Realization). Deux améliorations principales :
- Tables de relations autorisées plus complètes : chaque combinaison
(type source, type relation, type cible)est désormais soit explicitement autorisée, soit interdite. - Règles de dérivation clarifiées : les règles sont formulées de façon rigoureuse — une relation dérivée A → C n'existe que si la combinaison des relations A → B et B → C est listée comme dérivable dans les tables normatives.
Tables normatives en annexe
Les relations autorisées sont définies dans des tables normatives en annexe de la spécification. Un modèle valide en 3.2 reste valide en 4.0 — les nouvelles tables ne restreignent pas ce qui était autorisé, elles lèvent les ambiguïtés sur les cas non définis.
5. Révision de la sémantique des Junctions
En 3.2
Les Junction (AND-junction et OR-junction) permettaient de brancher des relations dynamiques (Triggering, Flow), mais leur sémantique dans les cas complexes avec plusieurs entrées et plusieurs sorties était peu précisée.
En 4.0
| Junction | Sémantique |
|---|---|
| AND-junction (entrée) | Attend que toutes les entrées soient activées avant de propager |
| AND-junction (sortie) | Propage vers toutes les sorties simultanément |
| OR-junction (entrée) | Se déclenche dès qu'au moins une entrée est activée |
| OR-junction (sortie) | Propage vers une ou plusieurs sorties selon des conditions |
Cette clarification est importante pour les modèles de processus complexes et les architectures événementielles.
6. Révision des niveaux de conformité
En 3.2
Deux niveaux de conformité : conforme ou non conforme. Cette binarité laissait peu de place aux extensions légitimes.
En 4.0
Trois niveaux explicites :
| Niveau | Définition |
|---|---|
| Conforme | Implémente tous les éléments, relations et règles normatives sans modification sémantique |
| Conforme en extension | Ajoute des éléments ou relations sans modifier la sémantique des éléments standards |
| Non conforme | Modifie la sémantique d'éléments normalisés ou omet des éléments obligatoires |
Intérêt pour les éditeurs d'outils
Le niveau « conforme en extension » permet aux éditeurs d'ajouter des fonctionnalités propriétaires (attributs supplémentaires, éléments de domaine spécifiques) tout en revendiquant légitimement une conformité partielle au standard.
7. Ce qui n'a pas changé
Les éléments et règles suivants sont inchangés dans leur sémantique :
- Tous les éléments des domaines Métier, Application et Implémentation & Migration
- L'ensemble des relations (Composition, Aggregation, Assignment, Realization, Serving, Access, Influence, Association, Triggering, Flow, Specialization)
- Les éléments communs (Grouping, Location, Junction — sémantique AND/OR clarifiée mais non modifiée)
- Le mécanisme de vues et de points de vue
- Les mécanismes de personnalisation (spécialisation, profils, attributs)
- La complémentarité avec TOGAF®
8. Guide de migration 3.2 → 4.0
| Situation dans un modèle 3.2 | Action recommandée en 4.0 |
|---|---|
| Éléments Physiques dans le domaine Technologie | Requalifier vers la couche Physical dans l'outil |
Relations Realization entre Capability et ses implémentations | Optionnel : introduire Capability Realization pour plus de traçabilité |
Value utilisé pour des objets concrets échangés | Optionnel : distinguer Value (abstrait) et Value Object (concret) |
| Junctions avec sémantique ambiguë | Vérifier l'alignement avec les nouvelles définitions AND/OR |
Vérifier la conformité de votre outil
Tous les outils du marché ne sont pas encore certifiés ArchiMate 4.0. Vérifier la feuille de route de votre éditeur avant d'entreprendre une migration de vos modèles.