Exemples ArchiMate
Dans cet article, vous verrez une riche collection d’exemples de vues ArchiMate, organisées dans un cadre en couches suivant la norme ArchiMate. Ces vues ArchiMate montrent comment les éléments ArchiMate peuvent être utilisés. Certains exemples peuvent être utilisés comme modèles de conception.
Les exemples sont conçus avec Visual Paradigm Online , basés sur les exemples du ArchiMate Cookbook. Si vous n’avez pas encore consulté le livre de cuisine, nous vous recommandons d’y jeter un coup d’œil. Lien : http://www.hosiaisluoma.fi/ArchiMate-Cookbook.pdf
ArchiMate Exemples de vues
Vue du cadre
Cette vue Framework structure toutes les vues utilisées. Il peut être utilisé pour la navigation entre les diagrammes.
Vues de motivation
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vue de la motivation peut être utilisée pour examiner les motivations, ou les causes, qui motivent la conception ou la transformation d’une organisation, ainsi que son architecture d’entreprise, qui sert de base à toutes les opérations de changement et à toutes les transformations commerciales au sein d’une entreprise. Cette vue décrit la vision de l’effort de développement, que l’échelle et la portée englobent l’ensemble de l’organisation, un sous-ensemble de celle-ci (par exemple, un secteur d’activité) ou un programme ou projet particulier (niveau de solution). Notez qu’une valeur peut être ajoutée à n’importe quel élément ArchiMate, tel que le résultat (ou tout autre élément ArchiMate), pour montrer quelle est la valeur ajoutée réelle.
Le Business Motivation Model (BMM) [spécification v.1.3, 2015, OMG] est utilisé pour définir les éléments de motivation.
Vision Mission-Valeurs-Vision
MODIFIER CE DIAGRAMME ARCHIMATE
Le but, la vision et les valeurs fondamentales de l’organisation peuvent tous être représentés à l’aide de la vue Mission-Valeurs-Vision. Il vous aide à identifier le but d’une organisation, ce que l’organisation fait réellement ou a l’intention de faire, et quelle est la principale raison de son existence. La vision est l’état souhaité de l’organisation dans le futur. La vision, la culture et les idéaux de l’organisation sont tous soutenus par des valeurs fondamentales. Les objectifs stratégiques doivent être atteints pour que la vision de l’organisation se concrétise.
Référence : Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Stratégie de modélisation avec ArchiMate.
Affichage de la carte des valeurs stratégiques
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Strategic Value Map visualise les stratégies d’une organisation. Toutes les opérations de développement doivent s’inspirer – directement ou indirectement – de cette vision, qui comporte des éléments de valeur stratégiques. Il est possible de suivre tous les autres aspects associés à l’exécution réelle de la stratégie en visualisant les valeurs stratégiques. L’approche peut être représentée, véhiculée et liée à la réalité avec cette perspective.
Vue Analyse des parties prenantes
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Analyse des parties prenantes est fréquemment utilisée pour l’analyse des parties prenantes afin d’identifier les moteurs de changement. Commencez par identifier les parties prenantes importantes, puis les moteurs de changement qui sont dans leur meilleur intérêt. Les concepts « d’évaluation » peuvent être utilisés pour une analyse approfondie des facteurs, comme l’utilisation de la technique SWOT (forces, faiblesses, opportunités et menaces). Différents diagrammes de vue des parties prenantes peuvent être générés à partir de différents points de vue, comme c’est la coutume. Une autre raison de diviser d’énormes diagrammes en plus petits est de les garder compacts et lisibles – dans un but de clarté.
Vue des parties prenantes
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vision des parties prenantes relie les motivations des parties prenantes aux objectifs de l’entreprise. Les objectifs sont la composante la plus importante du développement d’une organisation. Tous les éléments ultérieurs de toutes les actions de changement doivent être rattachés à ces raisons principales.
Affichage des principes
MODIFIER CE DIAGRAMME ARCHIMATE
Vue des risques et de la sécurité
MODIFIER CE DIAGRAMME ARCHIMATE
Les concepts de risque et de sécurité sont mappés à l’ArchiMate via cette vue. La gestion des risques inclut les préoccupations concernant la sécurité et la protection des données. Les deux sont couverts par cette vue.
Les références:
- Comment modéliser la gestion des risques et la sécurité de l’entreprise avec le langage ArchiMate®, Open Group, Document No : W172, 2017.
- Modélisation de la gestion des risques et de la sécurité de l’entreprise avec le langage ArchiMate®, Open Group, 2015.
Vue d’analyse SWOT
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage des objectifs
MODIFIER CE DIAGRAMME ARCHIMATE
Objectifs et résultats clés
MODIFIER CE DIAGRAMME ARCHIMATE
OKR, abréviation d’objectifs et de résultats clés, est une méthode de gestion populaire pour définir des objectifs et suivre les progrès. Il aide à créer un alignement et un engagement autour d’objectifs mesurables. Les OKR sont composés de deux parties : (1) l’objectif que vous souhaitez atteindre et (2) les résultats clés qui seront utilisés pour suivre votre progression vers cet objectif.
Les objectifs sont…
- Des explications qualitatives de ce que vous voulez accomplir qui sont mémorables. Des objectifs courts, inspirants et engageants sont idéaux. L’équipe doit être motivée et stimulée par l’objectif.
Les principaux résultats sont…
- Ensemble de mesures qui suivent vos progrès vers la réalisation de votre objectif. Vous devriez avoir deux à cinq résultats clés pour chaque cible. Avoir trop de résultats clés rendra difficile la mémorisation.
Une autre version avec les actions indiquées ci-dessous.
MODIFIER CE DIAGRAMME ARCHIMATE
Vues de stratégie
MODIFIER CE DIAGRAMME ARCHIMATE
Vue Stratégie
Les concepts liés à la stratégie d’entreprise tels que « Cours d’action », « Capabilité » et « Ressource » sont désormais disponibles dans la version 3 d’ArchiMate et peuvent être utilisés pour modéliser les plans d’affaires d’une organisation. L’utilité et la signification de cette vision résident dans la manière dont les objectifs de l’organisation peuvent être liés aux stratégies, puis à l’architecture d’entreprise via les capacités. Cette vision peut être utilisée pour appliquer le « modèle stratégique basé sur les objectifs » (Azevedo et al. 2015), dans lequel les objectifs forment une hiérarchie qui peut être disséquée en objectifs de niveau inférieur.
Vue Stratégie d’entreprise
MODIFIER CE DIAGRAMME ARCHIMATE
Vue du modèle de motivation commerciale (BMM)
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage des exigences
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vue Exigences peut être utilisée pour collecter les besoins en fonction des objectifs stratégiques. C’est le processus de connexion des stratégies aux implémentations : les stratégies peuvent être tracées jusqu’à leur exécution.
Vue de la stratégie à la capacité
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Strategy to Capability, ainsi que d’autres éléments ArchiMate tels que “Driver” et “Goal”, peuvent être utilisés pour la planification basée sur les capacités (CBP), comme indiqué dans le diagramme ArchiMate ci-dessous. Cette vue peut être utilisée pour faciliter la planification (et l’exécution) des stratégies. Par conséquent, ce type de perspective peut être utilisé dans la phase Strategy-to-Capability, qui fait partie de la phase « Strategy-to-Portfolio » d’IT4IT.
Affichage de la carte des capacités
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Carte des capacités peut être utilisée pour donner un aperçu de haut niveau des capacités d’une entreprise : ce qu’elle fait ou peut faire.
Vue Planification des capacités
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Planification des capacités peut être utilisée pour « le lien entre la stratégie et l’architecture d’entreprise », tel que défini par la planification basée sur les capacités (CBP). Cette approche peut être utilisée pour mapper les stratégies aux capacités requises et les capacités aux ressources et autres blocs de construction, entre autres choses.
Vue de réalisation des capacités
MODIFIER CE DIAGRAMME ARCHIMATE
Vue de réalisation des capacités 2
MODIFIER CE DIAGRAMME ARCHIMATE
Un autre exemple de la vue Réalisation de capacité qui montre comment définir les éléments qui peuvent être utilisés pour réaliser une capacité.
Vue de la chaîne de valeur
MODIFIER CE DIAGRAMME ARCHIMATE
Il est important de noter qu’au début d’une chaîne de valeur/flux de valeur, une « association dirigée » est utilisée. Les « étapes » de valeur peuvent être trouvées dans un flux de valeur. Une « chaîne de valeur », composée de flux de valeur, peut être analogue à un flux de valeur global de haut niveau. L’IT4IT (lien) introduit une chaîne de valeur qui comprend quatre flux de valeur : stratégie à portefeuille, exigence à déployer, demande à satisfaire et détection à corriger (lien).
Flux de valeur – Vue de cartographie croisée des capacités
MODIFIER CE DIAGRAMME ARCHIMATE
Un exemple simple de chaîne de valeur est présenté ci-dessous. L’élément ArchiMate Value Stream, qui est présenté dans l’édition ArchiMate 3.1, peut être utilisé pour modéliser les chaînes de valeur, les réseaux de valeur et les flux de valeur.
Il s’agit d’un exemple plus détaillé de la manière dont les capacités assistent (servent) le flux de valeur. Cette perspective peut être utilisée pour définir CE QUE fait l’entreprise (le modèle commercial) et POURQUOI les capacités sont nécessaires, ainsi que leur relation avec la création de valeur.
L’implémentation de référence du Lean EA Framework (LEAF) inclut cette vue (lien). Allez dans “Value Streams” puis “Value Delivery Chain”.
Vue du canevas du modèle d’entreprise
MODIFIER CE DIAGRAMME ARCHIMATE
Il s’agit d’une version de base du Business Model Canvas (BMC) d’A. Osterwalder, et il peut être modifié pour répondre à vos besoins. Des techniques versionnées telles que « Service Model Canvas » et « Lean Canvas » sont également disponibles. Un BMC peut être utilisé pour concevoir et innover des modèles commerciaux, par exemple.
« Facilite le suivi des exigences depuis les demandes commerciales jusqu’aux spécifications de conception » en modélisant un BMC avec ArchiMate. Cela aide à découvrir les conséquences des changements de modèles commerciaux sur la conception architecturale. [LO Meertens et collègues]
L’assistance à l’architecture intégrée pour l’analyse de la stratégie et du modèle commercial est incluse dans le développement holistique. Cela permet aux analystes commerciaux et aux développeurs d’évaluer dans quelle mesure le modèle commercial soutient la stratégie et s’intègre à l’organisation, et vice versa.
Lorsque le BMC est modélisé dans un outil de modélisation, un avantage de cette méthode est que tous les éléments du BMC peuvent être réutilisés dans d’autres vues du même référentiel de modèles. Lors du pivotement du modèle d’entreprise, tous les changements sont immédiatement évidents. Les modélisateurs métier peuvent construire de nouveaux éléments, tels que des services, ou utiliser tous les éléments existants du référentiel, tels que les unités organisationnelles et les ressources.
Vue de la toile conceptuelle
MODIFIER CE DIAGRAMME ARCHIMATE
Le BMC peut se présenter sous diverses formes, comme indiqué ci-dessus. L’approche en couches d’ArchiMate se reflète dans la mise en page de ce Concept Canvas.
Vues d’entreprise
Vues de la couche d’architecture métier.
Il existe différentes «cartes» d’éléments contrôlés dans l’outil EA dans chaque couche, telles que la carte des services commerciaux, la carte des processus, etc. Une fois que vous avez reconnu et introduit des cartes, vous pouvez les utiliser dans d’autres diagrammes (tels que des vues en couches). L’objectif des cartes est de gérer les catalogues « EA assets » comme des « portefeuilles » (analogues aux portefeuilles d’idées, de services et de projets, etc.). D’autres fonctionnalités, telles que des propriétés ou des attributs, sont souvent fournies par les outils EA pour chaque élément. Ceux-ci peuvent être utilisés pour fournir plus de détails sur chaque aspect. Ce type de données supplémentaires peut également être utilisé pour divers types d’analyse.
Chaque couche peut avoir plusieurs cartes, telles que les suivantes :
- Services commerciaux, acteurs commerciaux et processus commerciaux dans la couche commerciale ;
- Services d’application, applications dans la couche d’application ;
- Services technologiques, plates-formes et technologies de la couche technologique ; et ainsi de suite.
Voici quelques exemples de cartes de couche métier.
Vue cartographique des services aux entreprises
MODIFIER CE DIAGRAMME ARCHIMATE
La vue Carte des services métier fournit une vue d’ensemble des services métier de l’entreprise. À des fins de gestion, ce type de vue peut être utilisé comme « catalogue de services » ou « portefeuille de services ». Il est essentiel de déterminer le type de services commerciaux que l’entreprise offre à ses clients. Un service métier peut également être utilisé pour simuler tous les processus et structures organisationnels sous-jacents. Par conséquent, les services aux entreprises sont des composants essentiels de l’architecture d’entreprise.
Affichage de la carte des processus métier
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vue peut être utilisée comme une « carte des processus », qui fournit une vue d’ensemble des processus métier de l’organisation.
Vue de coopération des processus métier
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vue peut être utilisée pour modéliser le modèle opérationnel, par exemple.
Vue cartographique des acteurs commerciaux
MODIFIER CE DIAGRAMME ARCHIMATE
Il existe deux types d’actions commerciales : internes et externes. Les clients, partenaires commerciaux ou autres groupes de parties prenantes qui collaborent avec l’organisation sont des exemples d’acteurs commerciaux internes, tandis que les acteurs commerciaux externes sont des clients, des partenaires commerciaux ou d’autres groupes de parties prenantes qui collaborent avec l’entreprise (comme des organisations du secteur public ou d’autres autorités de gouvernance). ).
Vue sur la coopération des acteurs commerciaux
MODIFIER CE DIAGRAMME ARCHIMATE
Voici deux scénarios d’utilisation :
- Vue intra-entreprise : cette vue visualise la manière dont les acteurs internes de l’entreprise collaborent et partagent des informations.
- Vue inter-entreprise : une vue d’écosystème qui décrit l’environnement opérationnel dans lequel une organisation fonctionne. Un écosystème est un ensemble d’organisations et de partenaires commerciaux qui collaborent par le biais d’interactions. Il y a des fournisseurs, des sous-traitants et d’autres partenaires interentreprises, ainsi que des clients.
Vue des processus métier
MODIFIER CE DIAGRAMME ARCHIMATE
La vue des processus métier montre « la structure et la composition de haut niveau d’un processus métier (ou de nombreux processus), les services fournis, les rôles attribués aux acteurs et les informations utilisées par le processus métier ». Ce diagramme de processus comprend des éléments « Jonction » pour représenter la « bifurcation » et la « jointure » du flux de processus.
Vous trouverez ci-dessous une perspective de processus avancé. Il s’agit du modèle d’exploitation, qui est basé sur le modèle commercial décrit dans le diagramme de flux de valeur ci-dessus.
MODIFIER CE DIAGRAMME ARCHIMATE
SIPOC (Fournisseurs, Entrées, Processus, Sorties, Clients)
MODIFIER CE DIAGRAMME ARCHIMATE
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) est un outil Six Sigma qui peut être utilisé pour définir des aspects similaires à tous les processus. Il s’agit d’une méthode simple pour examiner l’analyse de rentabilisation : quelle valeur le client reçoit-il et comment la reçoit-il ?
Vue des processus métier avec des rôles métier en tant que « couloirs » d’un processus – Une approche en couches
MODIFIER CE DIAGRAMME ARCHIMATE
Le client est représenté par le « Rôle commercial A » et le parcours du client est représenté par la « ligne de nage » la plus élevée.
Notez que les rôles métier (visualisés sous forme de « couloirs ») sont imbriqués dans les étapes de processus (activités), ce qui implique que ces rôles métier sont affectés à ces processus métier/étapes de processus. Par conséquent, cette vue est un hybride d’une vue en couches et d’une vue des processus métier.
Les flux d’informations et de données sont représentés dans cette version (relation de flux). Le parcours du client est représenté par la « ligne de nage » supérieure (activités liées à la relation déclenchante).
MODIFIER CE DIAGRAMME ARCHIMATE
La méthodologie de conception de service est représentée ci-dessous. Le cheminement du parcours client (rôle A) est représenté par la « swimline » la plus élevée, qui est liée à l’organisation (rôles B et C) via les services commerciaux (1 et 2).
MODIFIER CE DIAGRAMME ARCHIMATE
Vue des processus métier en couches
Cette vue peut être utilisée pour représenter un processus métier avec des étapes manuelles et automatisées.
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage de la carte du parcours client
Lorsqu’un parcours client doit être étudié à un niveau élevé, cette version est générée en utilisant des éléments de motivation et de stratégie.
MODIFIER CE DIAGRAMME ARCHIMATE
Lorsque le chemin du service client doit être examiné plus en détail, cette version est générée à l’aide des parties de la couche métier et de la couche application (noyau).
MODIFIER CE DIAGRAMME ARCHIMATE
L’expérience client est au centre de cette vision centrée sur le client. Cette technique liée à la « conception de services » se concentre sur le développement « de l’extérieur vers l’intérieur » du service en cours de création. Cela souligne l’importance des services et des produits dans la création de valeur pour les clients – et indirectement pour l’organisation. Un itinéraire de parcours client peut être utilisé pour visualiser un flux de valeur client qui comprend de nombreux services d’application et applications.
Vue du plan de service
MODIFIER CE DIAGRAMME ARCHIMATE
Cette vue Service Blueprint est centrée sur le client et le service, mais elle met également en évidence l’aspect « inside-out » du service. La stratégie de développement axée sur les services peut identifier les implications comportementales et structurelles sous-jacentes du service qui doit être construit à l’aide de cette technique. Par conséquent, cette vue ajoute des facteurs de processus et fonctionnels à l’approche axée sur l’expérience client.
Cette vision peut se décliner sous différentes formes. Les flux d’informations entre les couches et les éléments font l’objet de cet exemple.
Vue de l’histoire de l’utilisateur
MODIFIER CE DIAGRAMME ARCHIMATE
Les user stories peuvent être visualisées à l’aide de cette vue.
Vue Modèles de service cloud
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage des informations
MODIFIER CE DIAGRAMME ARCHIMATE
Les niveaux d’abstraction suivants peuvent être utilisés pour modéliser l’information : a) conceptuel, b) logique et c) physique. Ces couches d’abstraction sont représentées dans le diagramme ci-dessus.
Vue Modèle de données conceptuel
MODIFIER CE DIAGRAMME ARCHIMATE
Les objets métier, également appelés concepts, utilisés dans les opérations métier sont contenus dans l’architecture d’informations de l’EA. Un modèle conceptuel de données peut être utilisé pour représenter ces concepts et leurs relations.
Notion de “Service”
MODIFIER CE DIAGRAMME ARCHIMATE
Le concept de service est souvent problématique, comme on peut le voir de diverses manières. Pour indiquer clairement de quel type de service il s’agit, il est judicieux d’utiliser le préfixe : service métier, application ou technologie. Selon ITIL, le service informatique est lié au service de production. Par conséquent. Le service informatique est le plus étroitement lié aux services applicatifs.
Service et produit
MODIFIER CE DIAGRAMME ARCHIMATE
Une notion de produit peut être utilisée pour agréger des services en tant qu’élément composite. Spécification selon ArchiMate :
“Un produit représente un ensemble cohérent de services et/ou d’éléments de structure passive, accompagné d’un contrat/ensemble d’accords, qui est proposé dans son ensemble à des clients (internes ou externes).”
« Un produit peut agréger ou composer des services métier, des services applicatifs et des services technologiques, des objets métier, des objets données et des objets technologiques, ainsi qu’un contrat. Ainsi, un produit peut agréger ou composer des éléments d’autres couches que la couche métier. ”
« Une valeur peut être associée à un produit. Le nom d’un produit est généralement le nom utilisé dans la communication avec les clients, ou éventuellement un nom plus générique (par exemple, “assurance voyage”). »
Vues des applications
Vue cartographique des services d’application
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage de la carte des applications
MODIFIER CE DIAGRAMME ARCHIMATE
Portefeuille d’applications, qui peut être séparé en divisions en fonction des unités commerciales, par exemple.
Vue de coopération d’application (flux de données)
MODIFIER CE DIAGRAMME ARCHIMATE
Vue d’intégration d’application (relations dynamiques)
Les exemples (1 à 10) ci-dessous montrent plusieurs techniques différentes pour simuler la commutation de données entre les applications.
- « L’application A » possède l’objet de données « A-1 », que « l’application B » demande.
- “L’application A” envoie des données à “l’application B”.
- “Application A” crée le service “A-1”, qui est utilisé par “Application B”.
- En pratique, “l’Application B” envoie une requête à “l’Application A-1” et reçoit une réponse…
MODIFIER CE DIAGRAMME ARCHIMATE
Vue de la structure de l’application
Cette vue est importante pour la conception ou l’analyse de la structure principale, des sous-composants et des données associées d’une application. Ce schéma peut être utilisé pour décomposer la structure d’un système applicatif en développement, pour démontrer la modularisation/décomposition : quels sont les sous-systèmes/sous-composants qu’ils alimentent, et quels sont les services applicatifs (ou interfaces applicatives) qu’ils donner.
MODIFIER CE DIAGRAMME ARCHIMATE
Les fonctionnalités comportementales fournies via les interfaces structurelles (GUI et/ou API dans l’image ci-dessous) sont appelées services applicatifs (figure ci-dessus). Les «différents côtés d’une même pièce» sont les services d’application et les interfaces d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Vue de l’architecture des applications
Étant donné qu’il existe à la fois des applications et des modules d’application dans la même vue, cette vue combine les techniques au niveau de l’EA et de la solution.
MODIFIER CE DIAGRAMME ARCHIMATE
Modèle de composant d’application (CM)
Le modèle de composant d’application 0-n est une technique de modélisation de l’architecture d’application qui se compose des diagrammes suivants de différents niveaux d’abstraction :
- Le diagramme au niveau CM-0 décrit comment l’application interagit avec son environnement, y compris comment elle interagit avec d’autres applications et utilisateurs. Une boîte noire est utilisée pour représenter l’application cible.
- L’application cible est décomposée en modules (composants principaux) et quels services d’application (ou interfaces d’application) ces modules fournissent et exigent au niveau CM-1. Une boîte blanche est utilisée pour représenter l’application cible.
- Les modules sont divisés en sous-composantes au niveau CM-2. (Le nombre de paliers essentiels varie selon les circonstances.)
Les composants d’application et les services d’application sont décrits dans les diagrammes du modèle de composant d’application (CM) ci-dessous. Selon la situation, les interfaces d’application peuvent être utilisées à la place des services d’application. Comme toujours, il est essentiel d’utiliser un style de modélisation adapté à la tâche à accomplir et de ne modéliser que les aspects suffisamment informatifs et à valeur ajoutée. Il appartient au modélisateur de mettre en évidence les fonctionnalités ou d’être plus détaillé et de modéliser, par exemple, les interfaces réelles avec une nomenclature précise.
Les composants d’application et les services d’application sont décrits dans les diagrammes de modèle de composant ci-dessous. Au lieu d’utiliser des services d’application, des interfaces d’application peuvent être utilisées.
Modèle de composant d’application – 0 (CM-0)
MODIFIER CE DIAGRAMME ARCHIMATE
Les interactions entre l’application cible et les applications environnantes sont représentées au niveau Modèle de composant – 0 (CM-0) (ci-dessus). Tous les services d’application (ou interfaces d’application) nécessaires sont décrits. Les composants de niveau architecture d’entreprise et leurs services sont représentés au niveau 0 du diagramme, avec l’application cible au milieu.
Modèle de composant d’application – 1 (CM-1)
MODIFIER CE DIAGRAMME ARCHIMATE
Le niveau Modèle de composant – 1 (CM-1) (ci-dessus) montre comment l’application cible est décomposée en modules (ou composants principaux) et quel module est responsable de quels services d’application (ou interfaces d’application). Note! Les applications externes ne sont pas tenues d’être affichées à ce niveau, mais leurs services (ou interfaces) le sont. Lorsque davantage de parties de bas niveau sont affichées, davantage d’éléments de haut niveau peuvent/doivent être omis – dans un souci de clarté : pour que le diagramme reste compréhensible.
Modèle de composant d’application – 2 (CM-2)
MODIFIER CE DIAGRAMME ARCHIMATE
Le niveau Modèle de composant – 2 (CM-2) (illustré ci-dessus) décrit comment les modules de l’application cible sont constitués de sous-composants et interagissent.
Vue Fonctions d’application
Décomposition des fonctionnalités applicatives : quelles sont les fonctions du système, et quels services applicatifs fournissent-elles ?
MODIFIER CE DIAGRAMME ARCHIMATE
Affichage du processus de candidature
MODIFIER CE DIAGRAMME ARCHIMATE
Voici la vue d’imbrication de la vue du processus d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Voici le contenu interne de la vue du processus d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Vue du diagramme de séquence des composants d’application
Les diagrammes de séquence ne sont pas exactement couverts par ArchiMate ; au lieu de cela, ils sont couverts par UML. Cependant, comme démontré ci-dessous, ArchiMate peut être utilisé pour modéliser des séquences d’opérations exécutées par les composants d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Pour modéliser la dynamique entre composants applicatifs, les relations dynamiques « Trigger » et « Flow » peuvent être employées. La disposition de cette vue est similaire à celle du diagramme de séquence UML.
Vue 2 du diagramme de séquence des composants d’application
Cette version (schéma ci-dessous) montre comment ArchiMate peut être utilisé pour modéliser les actions que les éléments internes des composants applicatifs effectuent. Les processus ou fonctions comportementaux, ainsi que les sous-composants structurels, sont des exemples de parties internes. Les éléments de processus d’application, de fonction d’application et de composant d’application sont utilisés pour les modéliser. Ceux-ci ne sont fournis qu’en tant qu’alternatives.
MODIFIER CE DIAGRAMME ARCHIMATE
Les actions dans ce diagramme de séquence (ci-dessus) sont les suivantes :
- Le sous-processus “X” du composant applicatif “A” envoie un message de demande à l’application B avec le paramètre “A”.
- Le sous-processus « B-1 » du composant d’application « B » reçoit la demande entrante, puis appelle (de manière synchrone) le composant d’application C, où la fonction d’application « Y » accepte la demande, effectue certaines actions et revient.
- L’autre sous-processus « B-2 » du composant applicatif « B » envoie un message avec des paramètres au composant applicatif D et reçoit un accusé de réception. Le sous-composant « D » du composant d’application « D » effectue le traitement.
- Le message de réponse du composant applicatif B est reçu par le composant applicatif “A”. Le diagramme de séquence a son propre objectif spécialisé dans la conception de logiciels, mais ArchiMate peut être utilisé à de nombreuses fins de modélisation, y compris dans la conception d’applications.
L’intégration d’applications (EA) est l’un des aspects les plus importants de l’architecture d’entreprise. C’est pourquoi il est utile de pouvoir décrire plus en détail comment les applications commutent les données et quelles méthodes d’interaction sont utilisées. Voici un lien vers le livre “Enterprise Integration Patterns”, qui est un endroit fantastique pour commencer à en apprendre davantage sur les modèles d’intégration.
La même idée d’exploiter les relations dynamiques ArchiMate Trigger et Flow, qui peuvent être utilisées pour modéliser des modèles de messagerie synchrones et asynchrones, est utilisée dans une séquence avec l’utilisateur final inclus (figure ci-dessous) (demande-réponse et rappel, également publier- abonnez-vous etc).
Vue du processus ETL
MODIFIER CE DIAGRAMME ARCHIMATE
Vue EAI/ESB
MODIFIER CE DIAGRAMME ARCHIMATE
Vue en couches
MODIFIER CE DIAGRAMME ARCHIMATE
La vue en couches peut être utilisée comme diagramme de contexte de vue d’ensemble de la zone cible. Le principal avantage de cette approche est qu’elle montre comment les applications sont utilisées dans les processus métier et quels services elles fournissent. Pour modéliser différentes couches, le diagramme ci-dessus utilise l’élément ArchiMate Grouping-element, tandis que le diagramme ci-dessous utilise l’élément visuel Group-element de l’outil.
ArchiMate comporte trois (3) couches, qui sont les suivantes : Les trois couches sont : 1) la couche métier, 2) la couche application et 3) la couche technologie. Ils sont généralement colorés comme suit : jaune pour la couche métier, turquoise pour la couche application et vert pour la couche technologie.
MODIFIER CE DIAGRAMME ARCHIMATE
Vue de l’application et de la base de données
Une base de données est un élément important de l’architecture d’entreprise globale d’une organisation. Par exemple, “Base de données client”, “Base de données client”, “Base de données produit”, etc. Alternativement, une base de données peut être une compilation logique (et physique) de toutes les tables d’une application (par exemple, “table Client”, “table Commandes”, “table Factures”, etc.), qui forment collectivement une base de données. Un Data Object peut être utilisé pour modéliser une base de données logique (figure ci-dessous), selon le standard ArchiMate. Le chapitre 9.4.1 « Objet de données » indique : « Des exemples typiques d’objets de données sont un enregistrement client, une base de données client ou une réclamation d’assurance. » “Une exception significative est lorsqu’un objet de données est utilisé pour modéliser une collection de données avec une seule instance, telle qu’une base de données. « ArchiMate comprend un système intégré intelligent qui vous permet d’appliquer le même concept à plusieurs niveaux d’abstraction (et niveaux de détails). Par conséquent, l’objet de données, par exemple, peut être utilisé pour simuler une base de données logique, une table de base de données, une structure de message (commutée entre les applications), etc.
MODIFIER CE DIAGRAMME ARCHIMATE
Base de données en tant que composant d’application
MODIFIER CE DIAGRAMME ARCHIMATE
Niveaux d’abstraction de la base de données :
MODIFIER CE DIAGRAMME ARCHIMATE
Vue Modèle de données :
MODIFIER CE DIAGRAMME ARCHIMATE
Voir les cas d’utilisation
ArchiMate peut être utilisé pour examiner les cas d’utilisation du point de vue fonctionnel d’une application. Comme illustré dans le diagramme ci-dessous, les cas d’utilisation (tels que définis par UML) peuvent être mappés aux services d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Un cas d’utilisation peut être divisé en deux catégories : les cas d’utilisation métier et les cas d’utilisation système (c’est-à-dire les cas système). Le diagramme ci-dessous montre comment un « cas d’utilisation principal » peut être représenté par un service métier, les cas système suivants étant représentés par des services d’application.
MODIFIER CE DIAGRAMME ARCHIMATE
Lorsque les cas d’utilisation sont définis en tant que services d’application, ils peuvent être utilisés comme éléments de fonctions d’application cible dans d’autres diagrammes (tels que la vue en couches). En d’autres termes, les services applicatifs représentent le comportement (fonctionnalités) d’une application. Voir ArchiMate Cookbook, lien, pour plus d’informations sur l’analyse des cas d’utilisation.
Vues technologiques
Vues des couches d’architecture technologique.
Vue des infrastructures
Cette vue décrit la plate-forme d’une application. Ce modèle peut être utilisé pour modéliser une configuration d’environnement d’exécution ainsi que le déploiement d’une application métier.
MODIFIER CE DIAGRAMME ARCHIMATE
Vue Infrastructure (imbrication) :
MODIFIER CE DIAGRAMME ARCHIMATE
Couche d’implémentation et de migration / Vues de la couche d’architecture de transformation
Feuille de route de mise en œuvre
MODIFIER CE DIAGRAMME ARCHIMATE
Vue Kanban
MODIFIER CE DIAGRAMME ARCHIMATE
Le tableau Kanban est un outil de visualisation du travail et des processus. Le tableau Kanban décrit comment les besoins de développement, les epics, les user stories et d’autres éléments passent du backlog à l’état prêt (Terminé). Selon le volume et l’étendue du scénario de développement, un tableau Kanban peut être utilisé à diverses fins. Par exemple, “Epics” peut être utilisé au niveau EA, et “User Stories” ou “Requirements” peuvent être utilisés comme éléments de travail au niveau du projet. Selon la situation, la granularité des éléments de tâche peut varier.
Vue générique
MODIFIER CE DIAGRAMME ARCHIMATE
Cette représentation simplifiée peut être utilisée comme diagramme de contexte pour un service, un programme ou un projet spécifique, par exemple.
Suppléments
Aperçu du contexte – La carte de la Voie lactée
Il s’agit d’une technique permettant de visualiser le plus possible en un seul regard. Voir la carte de la voie lactée avec ArchiMate pour plus d’informations.
MODIFIER CE DIAGRAMME ARCHIMATE
Vue de coopération
Comme le montre l’exemple de diagramme de flux de données ci-dessous, les couches peuvent être mélangées.
MODIFIER CE DIAGRAMME ARCHIMATE
Métamodèle
MODIFIER CE DIAGRAMME ARCHIMATE
Ces exemples sont créés avec Visual Paradigm Online .
