THOT ITArchiMate 4.0
Synthèse complète du standard ArchiMate 4.0 : structure du langage, domaines, éléments, relations et vues.
ArchiMate® 4.0 est la version majeure publiée par The Open Group en 2024. Elle apporte des clarifications structurelles importantes par rapport à la série 3.x, notamment la formalisation du domaine Physique en couche indépendante, de nouveaux éléments dans les domaines Motivation et Stratégie, et une révision des règles de conformité.
La documentation officielle est disponible gratuitement (inscription requise) sur pubs.opengroup.org/architecture/archimate4-doc.
Structure du langage
Aspects
ArchiMate organise les éléments selon trois aspects transverses à toutes les couches :
| Aspect | Description |
|---|---|
| Structure active | Entités qui exercent un comportement (acteurs, composants, nœuds) |
| Comportement | Actions réalisées par les entités (processus, fonction, service, événement) |
| Structure passive | Objets sur lesquels s'exerce le comportement (données, objets métier) |
Couches
| Couche | Objet |
|---|---|
| Motivation | Pourquoi : parties prenantes, objectifs, exigences |
| Stratégie | Ressources et capacités stratégiques |
| Métier | Processus, fonctions, services et acteurs métier |
| Application | Composants logiciels, services applicatifs, données |
| Technologie | Infrastructure logicielle et matérielle informatique |
| Physique | Infrastructure matérielle physique non informatique |
| Implémentation & Migration | Programmes, paquets de travail, plateaux |
Principes de conception
- Chaque couche expose des services à la couche supérieure via des relations de Réalisation et de Desserte.
- Les éléments d'une couche peuvent être regroupés en collaborations ou interactions.
- La couche Physique est désormais clairement distincte de la couche Technologie : la Technologie couvre l'IT (serveurs, OS, réseau), le Physique couvre le monde réel (bâtiments, machines industrielles).
- ArchiMate est complémentaire à TOGAF® : ArchiMate est le langage, TOGAF est la méthode.
Domaine Motivation
Le domaine Motivation modélise les raisons qui guident les choix architecturaux.
| Élément | Nouveauté 4.0 | Description |
|---|---|---|
| Stakeholder | Partie prenante ayant un intérêt dans l'architecture | |
| Driver | Facteur interne ou externe qui motive le changement | |
| Assessment | Évaluation d'un driver (force, faiblesse, opportunité, menace) | |
| Goal | Objectif de haut niveau à atteindre | |
| Outcome | Résultat attendu, mesurable | |
| Principle | Règle directrice pour les décisions d'architecture | |
| Requirement | Besoin à satisfaire pour atteindre un objectif | |
| Constraint | Limitation qui restreint la solution | |
| Value | Valeur perçue par les parties prenantes | |
| Value Object | ✦ nouveau | Représentation explicite et tangible d'une valeur échangée ou créée |
| Meaning | Signification attribuée à un concept dans un contexte donné |
Value Object vs Value
Value exprime une valeur perçue de façon abstraite (ex. : « réduction des coûts »). Value Object représente un objet concret porteur de valeur qui s'échange entre parties (ex. : un bon de commande, un rapport financier). Cette distinction est nouvelle en 4.0.
Domaine Stratégie
Le domaine Stratégie modélise les ressources et capacités nécessaires à la réalisation de la vision.
| Élément | Nouveauté 4.0 | Description |
|---|---|---|
| Resource | Actif (humain, matériel, financier, informationnel) mobilisé pour exercer une capacité | |
| Capability | Aptitude d'une organisation à atteindre un objectif dans un contexte donné | |
| Capability Realization | ✦ nouveau | Lien explicite entre une capacité et les éléments concrets qui la réalisent |
| Value Stream | Séquence d'activités créant de la valeur pour une partie prenante | |
| Course of Action | Approche ou plan pour atteindre un objectif stratégique |
Capability Realization
En 4.0, la relation entre une Capability et son implémentation (processus, application, infrastructure) passe par un élément formel Capability Realization, qui peut être associé à un Plateau dans le domaine Implémentation & Migration. Cela renforce la traçabilité stratégie → exécution.
Domaine Métier
Le domaine Métier modélise l'organisation, les processus et les services vus du point de vue business.
Structure active
| Élément | Description |
|---|---|
| Business Actor | Entité organisationnelle (personne, département) qui réalise un comportement |
| Business Role | Responsabilité assignée à un acteur dans un contexte donné |
| Business Collaboration | Coopération temporaire de rôles pour réaliser un comportement commun |
| Business Interface | Point d'accès exposant un service métier à l'environnement |
Comportement
| Élément | Description |
|---|---|
| Business Process | Séquence d'activités produisant un résultat métier |
| Business Function | Regroupement de comportements selon une compétence métier |
| Business Interaction | Comportement réalisé par une collaboration |
| Business Event | Changement d'état déclenchant ou résultant d'un comportement |
| Business Service | Service exposé à l'environnement par un rôle ou une collaboration |
"Structure passive
| Élément | Description |
|---|---|
| Business Object | Concept manipulé dans le domaine métier (contrat, commande…) |
| Contract | Accord formel définissant des droits et obligations |
| Representation | Forme perceptible d'un objet métier (document, formulaire…) |
| Product | Ensemble cohérent de services et contrats offerts à des clients |
Domaine Application
Le domaine Application modélise les systèmes logiciels et leurs interactions.
Structure active
| Élément | Description |
|---|---|
| Application Component | Unité logicielle autonome réalisant des fonctions applicatives |
| Application Collaboration | Agrégation temporaire de composants pour un comportement commun |
| Application Interface | Point d'accès exposant les fonctionnalités d'un composant |
Comportement
| Élément | Description |
|---|---|
| Application Function | Comportement automatisé réalisé par un composant |
| Application Interaction | Comportement réalisé par plusieurs composants en collaboration |
| Application Process | Séquence d'activités applicatives |
| Application Event | Événement déclenché ou produit par une application |
| Application Service | Service exposé par un composant à l'environnement |
Structure passive
| Élément | Description |
|---|---|
| Data Object | Donnée structurée persistante manipulée par les applications |
Domaine Technologie
Le domaine Technologie modélise l'infrastructure informatique (IT) qui supporte les applications. En 4.0, il se distingue clairement du domaine Physique.
Structure active
| Élément | Description |
|---|---|
| Node | Ressource computationnelle sur laquelle des artefacts sont déployés |
| Device | Ressource matérielle informatique (serveur, ordinateur, équipement réseau) |
| System Software | Logiciel de base (OS, middleware, SGBD, hyperviseur) |
| Technology Collaboration | Agrégation de nœuds pour un comportement commun |
| Technology Interface | Point d'accès d'un nœud |
| Path | Lien de communication entre nœuds |
| Communication Network | Ensemble de nœuds et chemins de communication |
Comportement
| Élément | Description |
|---|---|
| Technology Function | Comportement automatisé réalisé par un nœud |
| Technology Process | Séquence d'activités technologiques |
| Technology Interaction | Comportement réalisé par plusieurs nœuds |
| Technology Event | Événement déclenché ou produit par l'infrastructure |
| Technology Service | Service exposé par l'infrastructure |
Structure passive
| Élément | Description |
|---|---|
| Artifact | Donnée physique (fichier, exécutable, script, image) stockée sur un nœud |
Domaine Physique ✦ formalisé en 4.0
Le domaine Physique modélise l'infrastructure matérielle non informatique : bâtiments, machines industrielles, réseaux de distribution physique. Il était présent dans la série 3.x mais est désormais une couche indépendante avec ses propres éléments distincts de la Technologie.
Structure active
| Élément | Description |
|---|---|
| Facility | Espace physique (bâtiment, salle, entrepôt, data center) qui héberge du matériel ou des processus |
| Equipment | Machine ou appareil physique réalisant une fonction physique (robot, machine-outil, capteur) |
| Distribution Network | Infrastructure physique de distribution (réseau électrique, pipeline, réseau routier) |
Comportement
| Élément | Description |
|---|---|
| Physical Function | Comportement réalisé par un équipement physique |
| Physical Process | Séquence d'activités physiques |
| Physical Interaction | Comportement physique réalisé par plusieurs équipements |
| Physical Event | Événement se produisant dans le monde physique |
| Physical Service | Service exposé par une ressource physique |
Structure passive
| Élément | Description |
|---|---|
| Material | Objet physique tangible traité ou produit (matière première, pièce, produit fini) |
Physique vs Technologie
- Technology / Device → équipement informatique (serveur, switch, PC)
- Physical / Equipment → machine non informatique (convoyeur, presse, capteur industriel)
- Physical / Facility → espace qui contient des Devices et des Equipments
Domaine Implémentation & Migration
Ce domaine modélise la conduite du changement architectural, de l'état actuel vers l'état cible.
| Élément | Description |
|---|---|
| Work Package | Ensemble de tâches planifiées pour produire un résultat défini |
| Deliverable | Résultat précis et vérifiable d'un Work Package |
| Implementation Event | Événement se produisant pendant la phase d'implémentation |
| Plateau | État stable de l'architecture à un instant donné (actuel, intermédiaire, cible) |
| Gap | Écart entre deux Plateaux — ce qui doit être ajouté, modifié ou retiré |
Éléments communs (tous domaines)
| Élément | Description |
|---|---|
| Grouping | Agrégation libre d'éléments selon un critère quelconque (ne porte pas de sémantique forte) |
| Location | Emplacement conceptuel ou physique associé à d'autres éléments |
| Junction | Point de branchement pour les relations dynamiques (AND-junction / OR-junction) |
Relations
Relations structurelles
| Relation | Notation | Description |
|---|---|---|
| Composition | ◆— | Un élément est composé d'autres ; ils partagent le même cycle de vie |
| Aggregation | ◇— | Un élément regroupe d'autres ; cycles de vie indépendants |
| Assignment | ←— | Un acteur/rôle est assigné à un comportement ou une ressource |
| Realization | ╌▷ | Un élément concret réalise un élément abstrait (ex. : processus → service) |
Relations de dépendance
| Relation | Notation | Description |
|---|---|---|
| Serving | —▷ | Un élément fournit ses fonctionnalités à un autre |
| Access | ╌ | Un comportement lit (R), écrit (W) ou exécute (X) un objet passif |
| Influence | ╌╌▷ | Un élément influence positivement (+) ou négativement (−) un autre |
| Association | — | Relation non typée entre deux éléments |
Relations dynamiques
| Relation | Description |
|---|---|
| Triggering | Un comportement déclenche immédiatement un autre (causalité forte) |
| Flow | Transfert d'information ou de ressources entre comportements (flux continu) |
Autres relations
| Relation | Description |
|---|---|
| Specialization | Un élément ou une relation est une spécialisation d'un autre (héritage de sémantique) |
Règles de dérivation (4.0)
En 4.0, les tables de relations autorisées et les règles de dérivation sont révisées et rendues plus explicites. Principe général : si A → B et B → C avec des relations compatibles, on peut dériver A → C.
Attention aux tables normatives
Les relations autorisées entre types d'éléments sont définies dans des tables normatives en annexe de la spécification. En 4.0, ces tables intègrent le domaine Physique et les nouveaux éléments. Toujours se référer à la spec officielle pour valider les relations dans un modèle.
Vues et Points de vue
- Vue : représentation d'un système selon les préoccupations d'un ou plusieurs intervenants. Une vue est produite à partir d'un modèle.
- Point de vue : convention définissant comment construire et interpréter une vue (quels éléments inclure, quelles relations représenter).
Points de vue standards
| Point de vue | Couches concernées | Audience |
|---|---|---|
| Organisation | Métier | Responsables métier, DRH |
| Coopération d'acteurs | Métier | Architectes métier |
| Processus métier | Métier | Responsables processus |
| Produit | Métier | Product managers |
| Application | Application | Architectes applicatifs |
| Coopération applicative | Application | Architectes SI |
| Infrastructure | Technologie | Architectes infrastructure |
| Implémentation et déploiement | Application + Technologie | Architectes techniques |
| Physique | Physique | Architectes industriels, facility managers |
| Migration | Implémentation | Chefs de programme |
| Motivation | Motivation | Direction, parties prenantes |
| Stratégie | Stratégie | Direction, architectes d'entreprise |
Personnalisation et conformité
Mécanismes de personnalisation
ArchiMate 4.0 supporte l'extension du langage via :
- Spécialisation : créer un sous-type d'un élément ou d'une relation existant, en héritant de sa sémantique.
- Profil : ensemble cohérent de spécialisations adapté à un domaine (profil cloud, profil cybersécurité, profil IoT).
- Attributs supplémentaires : propriétés additionnelles attachées à n'importe quel élément ou relation.
Niveaux de conformité en 4.0
| Niveau | Description |
|---|---|
| Conforme | Implémente tous les éléments, relations et règles normatives sans modification |
| Conforme en extension | Ajoute des éléments ou relations sans altérer la sémantique des éléments standards |
| Non conforme | Modifie la sémantique d'éléments normalisés ou omet des éléments obligatoires |