ArchiMate 4 – Chapitre 6 : Domaine Motivation
Le Domaine Motivation représente les motivations et intentions des parties prenantes qui guident la conception et le changement d'architectures d'entreprise. Il répond à la question fondamentale : pourquoi l'architecture est-elle conçue de cette façon ?
Le domaine Motivation est essentiel pour relier les décisions architecturales aux raisons qui les ont motivées. Il permet de tracer la chaîne de raisonnement depuis les préoccupations des parties prenantes jusqu'aux exigences concrètes, en passant par les objectifs et les principes.
6.1. Éléments de motivation
Le domaine Motivation comprend les éléments suivants :
| Élément | Traduction | Rôle |
|---|---|---|
| Stakeholder | Partie prenante | Qui est concerné ? |
| Driver | Facteur | Qu'est-ce qui force le changement ? |
| Assessment | Évaluation | Quelle est la situation actuelle ? |
| Goal | Objectif | Qu'est-ce qu'on veut atteindre ? |
| Outcome | Résultat attendu | Quel est le résultat concret visé ? |
| Principle | Principe | Quelle règle guide les décisions ? |
| Requirement | Exigence | Que doit-on faire concrètement ? |
| Constraint | Contrainte | Qu'est-ce qui limite les choix ? |
| Meaning | Signification | Que signifie quelque chose pour une partie prenante ? |
| Value | Valeur | Quelle est l'importance accordée à quelque chose ? |
6.2. Métamodèle des éléments de motivation
Les éléments de motivation s'articulent selon la chaîne causale suivante :
Stakeholder → (a des) Driver(s)
Driver → (mène à) Assessment
Assessment → (identifie) Goal / Outcome
Goal → (est guidé par) Principle
Goal → (est formalisé en) Requirement / Constraint
Requirement → (réalise) Elements d'architecture
6.3. Partie prenante, Facteur et Évaluation
6.3.1. Partie prenante (Stakeholder)
Une Partie prenante (Stakeholder) est un rôle joué par un individu, une équipe ou une organisation (ou une classe de ceux-ci) ayant un intérêt ou une préoccupation dans l'issue d'une architecture.
Les parties prenantes ont des préoccupations (concerns) qui doivent être adressées par l'architecture. Elles définissent les points de vue appropriés pour communiquer avec chaque partie prenante.
Exemples : Conseil d'administration, DSI, Responsable métier, Équipe de développement, Client, Régulateur.
6.3.2. Facteur (Driver)
Un Facteur (Driver) représente une condition interne ou externe qui motive une organisation à opérer des changements et à atteindre ses objectifs.
Les drivers peuvent être internes (optimisation des coûts, efficacité opérationnelle) ou externes (réglementation, concurrence, technologie émergente).
Exemples : Pression réglementaire (RGPD), Transformation numérique, Réduction des coûts, Satisfaction client.
6.3.3. Évaluation (Assessment)
Une Évaluation (Assessment) représente le résultat d'une analyse d'une situation en regard d'un facteur. Il peut s'agir d'une analyse de forces et faiblesses (SWOT), d'une analyse d'écart (gap analysis), etc.
Exemples : Analyse SWOT, Rapport d'audit, Analyse d'impact réglementaire, Benchmark de performance.
6.4. Objectif, Résultat, Principe et Exigence
6.4.1. Objectif (Goal)
Un Objectif (Goal) est un résultat final qu'une partie prenante veut atteindre. Les objectifs peuvent être décomposés en sous-objectifs et peuvent confluer ou être en tension.
Exemples : « Réduire le délai de mise sur le marché de 30% », « Atteindre 99,9% de disponibilité des systèmes critiques ».
6.4.2. Résultat attendu (Outcome)
Un Résultat attendu (Outcome) est un résultat final qu'une partie prenante souhaite atteindre, exprimé en termes de valeur créée ou de changement réalisé pour les parties prenantes. À la différence d'un Objectif, il est centré sur l'impact plutôt que sur la performance.
Exemples : « Amélioration de l'expérience client », « Réduction du risque réglementaire ».
6.4.3. Principe (Principle)
Un Principe (Principle) est une affirmation d'intention qui guide la conception et le développement de l'architecture. Il représente des règles fondamentales qui s'appliquent à l'ensemble de l'organisation.
Exemples : « Privilegier les solutions Cloud-first », « Toute donnée personnelle doit être chiffrée », « Les API publiques doivent respecter le standard REST ».
6.4.4. Exigence (Requirement)
Une Exigence (Requirement) est une déclaration de besoin qui doit être réalisée par le système. Elle formalise concrètement ce que l'architecture doit faire pour atteindre les objectifs.
Exemples : « Le système doit répondre en moins de 2 secondes », « L'authentification doit utiliser MFA », « Les données doivent être stockées en Europe ».
6.4.5. Contrainte (Constraint)
Une Contrainte (Constraint) est une restriction qui limite les options de conception de l'architecture. À la différence d'une exigence, une contrainte ne peut généralement pas être questionnée ou négociée.
Exemples : Budget limité, Délai imposé, Technologie imposée par le groupe, Norme réglementaire obligatoire.
6.5. Signification et Valeur
6.5.1. Signification (Meaning)
Une Signification (Meaning) est la connaissance ou l'expertise présente dans, ou représentée par, un concept. Elle est relative à une partie prenante : un même concept peut avoir des significations différentes pour des parties prenantes différentes.
Usage : documenter le sens donné à des concepts architecturaux pour différentes audie