Vues exemples ArchiMate : galerie complète – Motivation, Stratégie, Activité, Application, Technologie et Migration

Vue du cadre

Vue du cadre.

Cette vue représente le cadre pour construire tous les aspects du développement et les diagrammes associés. Cette vue peut être modifiée selon la situation. Elle peut donc être utilisée pour naviguer entre les diagrammes. Cette version de la vue est appliquée à partir du cadre ArchiMate (3). La motivation est introduite ici comme une « couche » plutôt qu’un « aspect ».

Point de vue de la motivation

Point de vue de la motivation

Point de vue de la motivation.

Cette vue peut être utilisée pour analyser les motivations ou moteurs qui guident l’organisation et sa conception ou transformation de l’architecture d’entreprise. Ces analyses de motivation constituent le point de départ de toutes les activités de changement ou transformations commerciales au sein de l’organisation. Cette vue représente la vision du travail de développement — que le périmètre et l’échelle couvrent l’organisation entière ou une partie de celle-ci (par exemple, une ligne d’activité) ou un seul programme ou projet (niveau solution). Remarque : Une valeur peut être ajoutée à un élément ArchiMate, par exemple Outcome (ou tout autre élément ArchiMate), pour indiquer la véritable valeur ajoutée !

Les éléments de motivation sont fondés sur le modèle de motivation d’entreprise (BMM) [spécification v.1.3, 2015, OMG].

Vue Mission – Vision – Valeurs

Mission – Vision – Valeurs.

Cette vue peut être utilisée pour représenter la mission, la vision et les valeurs fondamentales de l’organisation. La mission exprime, par exemple, « Quel est le but de l’organisation, ce qu’elle fait réellement ou entend faire, et quelle est la raison principale de son existence ? » La vision est l’état futur vers lequel l’organisation souhaite évoluer. Les valeurs fondamentales soutiennent la vision, façonnent la culture et reflètent les valeurs de l’organisation. Pour réaliser la vision de l’organisation, des objectifs stratégiques doivent être atteints.

Référence : Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Modélisation de la stratégie avec ArchiMate.

Vue Carte de valeur stratégique

Carte de valeur – Vue Carte de stratégie.

Cette vue peut être utilisée pour visualiser la stratégie de l’organisation. Elle contient des éléments de valeur stratégique, et toutes les activités de développement doivent être dérivées — directement ou indirectement — des éléments de valeur stratégique. En visualisant la valeur stratégique, il devient possible de suivre tous les autres éléments liés à l’exécution stratégique réelle. Grâce à cette vue, la stratégie peut être rendue concrète : visualisée, communiquée et reliée à la réalité.

Vue d’analyse des parties prenantes

Vue d’analyse des parties prenantes.

Cette vue peut être utilisée pour l’analyse des parties prenantes dans le cadre du développement commercial : quels sont les moteurs du changement ? Tout d’abord, les parties prenantes pertinentes sont identifiées, puis les moteurs du changement qui s’alignent sur leurs intérêts sont déterminés. Le concept « Évaluation » peut être utilisé pour analyser plus en détail les moteurs, par exemple selon l’approche SWOT (Forces, Faiblesses, Opportunités, Menaces). En général, des vues différentes des parties prenantes peuvent être créées à partir de différents points de vue. Une autre raison de diviser le grand tableau en éléments plus petits est de garder les diagrammes compacts et lisibles — pour plus de simplicité.

Point de vue des parties prenantes

Point de vue des parties prenantes.

Cette vue peut être utilisée pour relier les moteurs des parties prenantes aux objectifs commerciaux. Les objectifs sont des éléments clés du développement de l’organisation. Tous les éléments ultérieurs doivent être rattachés à ces moteurs principaux de toutes les activités de changement.

Vue des principes

Vue des principes.

Vue Risque et Sécurité

Vue Risque et Sécurité. Mappage des concepts de risque et de sécurité sur ArchiMate. Les questions de sécurité et de protection des données font partie de la gestion des risques. Cette approche de modélisation couvre les deux aspects.

Références :

• Comment modéliser la gestion des risques et la sécurité d’entreprise avec le langage ArchiMate®, The Open Group, Numéro de document : W172, 2017.
• Modélisation de la gestion des risques et de la sécurité d’entreprise avec le langage ArchiMate®, The Open Group, 2015.

Vue d’analyse SWOT

Vue d’analyse SWOT.

Vue des objectifs

Vue des objectifs (avec élément Valeur).

Objectifs et résultats clés

Modèle OKR.

L’OKR est une stratégie de gestion populaire pour définir des objectifs et suivre les résultats. Il aide à créer une alignement et une implication autour des objectifs mesurables. Les OKR ont deux parties importantes : l’objectif que vous souhaitez atteindre et les résultats clés, qui sont la manière dont vous mesurez l’atteinte de l’objectif.

Objectif :

• Une description qualitative, mémorable de ce que vous souhaitez atteindre. Les objectifs doivent être courts, inspirants et engageants. Un objectif doit motiver et défier l’équipe.

Résultats clés :

• Un ensemble de métriques qui mesurent votre progression vers l’objectif. Vous devriez avoir de 2 à 5 résultats clés par objectif. Pas trop, sinon personne ne les retiendra.

Une autre version de l’OKR est présentée ci-dessous.

Modèle OKR (2).

Point de vue Stratégie

Vue de la couche Stratégie

Vue Stratégie

Vue Stratégie.

ArchiMate version 3 prend désormais en charge des concepts liés à la stratégie d’entreprise, tels que « Parcours d’action », « Capacité » et « Ressource », qui peuvent être utilisés pour modéliser la stratégie d’entreprise d’une organisation. La valeur et l’importance de cette vue réside dans le fait que les objectifs de l’organisation peuvent être liés à la stratégie, et dans la manière dont ils sont liés à l’architecture d’entreprise à travers les capacités. Cette vue peut être utilisée pour appliquer la « modélisation stratégique basée sur les objectifs » (Azevedo et al., 2015), où les objectifs forment une hiérarchie permettant de décomposer les objectifs de haut niveau en objectifs de niveau inférieur.

Vue Stratégie d’entreprise

Stratégie d’entreprise.

Vue du modèle de motivation d’entreprise (BMM)

Vue du modèle de motivation d’entreprise (BMM).

Vue des exigences

Vue des exigences.

Cette vue peut être utilisée pour recueillir des exigences basées sur des objectifs stratégiques. Cela lie la stratégie à la réalisation : la stratégie peut être suivie jusqu’à l’exécution.

Vue de la stratégie vers la capacité

Vue de la stratégie vers la capacité.

Cette vue peut être utilisée, par exemple, pour des fins de planification basée sur les capacités (CBP), ainsi que pour d’autres concepts ArchiMate tels que « Pilote » et « Objectif », comme indiqué dans la figure ci-dessous. Cette vue peut être utilisée pour soutenir les objectifs de planification stratégique (et d’exécution). Ainsi, cette vue peut être utilisée pour la phase Stratégie-vers-capacité, qui peut être incluse dans la « Stratégie-vers-Portefeuille » d’IT4IT.

Vue de la carte des capacités

Vue Cartographie des Capacités.

Cette vue peut être utilisée pour obtenir un aperçu des capacités de l’organisation : ce que l’organisation fait ou peut faire.

Vue Planification des Capacités

Vue Planification des Capacités.

Cette vue peut être utilisée par exemple à des fins de planification basée sur les capacités (CBP), c’est-à-dire « le lien entre la stratégie et l’architecture d’entreprise ». Cette vue peut être utilisée par exemple pour relier la stratégie aux capacités nécessaires, et les capacités aux ressources et aux autres éléments de construction.

Vue Réalisation des Capacités

Vue Réalisation des Capacités.

Vue Réalisation des Capacités 2

Une autre vue définissant comment les capacités sont réalisées par quels éléments…

Vue Réalisation des Capacités 2.

Vue Flux de Valeur

Vue Flux de Valeur (modèle).

Remarque ! « Association dirigée » utilisée au début de la chaîne de valeur / flux de valeur. Un flux de valeur peut se composer de « phases » de valeur. De même, un flux de valeur global et de haut niveau peut être une « chaîne de valeur », qui à son tour se compose de flux de valeur. Par exemple, IT4IT (lien) introduit une chaîne de valeur composée de quatre flux de valeur comme suit : Stratégie de portefeuille, Déploiement de la demande, Exécution de la demande, Détection à correction (lien).

Vue Croisement Flux de Valeur – Capacités

Un exemple simple d’une chaîne de livraison de valeur est présenté ci-dessous. Les chaînes de valeur, les réseaux de valeur et les flux de valeur peuvent être modélisés à l’aide de l’élément Flux de Valeur ArchiMate, inclus dans la version ArchiMate 3.1.

Vue d’exemple de chaîne de valeur Idée à Production.

Chaîne de livraison de valeur. Il s’agit d’un exemple étendu qui illustre comment les fonctions soutiennent (servent) le flux de valeur. Cette vue peut être utilisée pour définir ce que fait l’organisation (modèle économique), pourquoi les capacités sont nécessaires, et quel est leur lien avec la création de valeur.

Cette vue est incluse dans l’implémentation de référence du cadre Lean EA (LEAF) (lien). Accédez à « Flux de valeur », « Chaîne de livraison de valeur ».

Vue Tableau de bord du Modèle d’Affaires

Vue Modèle d’Affaires.

Il s’agit de la forme de base du Tableau de bord du Modèle d’Affaires (BMC), mais il peut être adapté selon la situation. Il existe également des approches versionnées, telles que « Tableau de bord du Modèle de Service » ou « Tableau de bord Lean ». Le BMC peut être utilisé par exemple pour la conception et l’innovation de modèles d’affaires.

La modélisation du BMC avec ArchiMate « permet de suivre les exigences depuis les besoins métiers jusqu’aux spécifications de conception. Cela aide à découvrir l’impact des changements de modèle d’affaires sur la conception architecturale. » [LO Meertens et al.]

Le développement global inclut un support architectural intégré pour l’analyse de la stratégie et du modèle d’affaires. Cela permet aux analystes métier et aux développeurs d’observer, par exemple, comment le modèle d’affaires soutient la stratégie et comment le modèle d’affaires s’adapte à l’organisation, et réciproquement.

Si le BMC est modélisé dans un outil de modélisation, l’avantage de cette approche est que tous les éléments du BMC peuvent être utilisés dans d’autres vues du même référentiel de modèles. Lorsque le modèle d’affaires est pivoté, tous les changements deviennent immédiatement visibles. Les modélisateurs métier peuvent créer de nouveaux éléments (par exemple, des services) ou utiliser tous les éléments existants du référentiel (par exemple, des unités organisationnelles ou des ressources).

Vue du canevas conceptuel

Canevas conceptuel. Le BMC peut présenter différentes variantes, comme indiqué dans la figure ci-dessous. La mise en page de ce canevas conceptuel est conforme à l’approche en couches d’ArchiMate.

Point de vue métier

Vue de la couche d’architecture métier.

Vue de la carte des services métiers

Vue des services métiers.

Cette vue fournit un aperçu des services métiers de l’organisation. Cette vue peut être utilisée comme un « catalogue de services » ou un « portefeuille de services » pour la gestion. Il est très important d’identifier quels services métiers l’organisation fournit à ses clients. En outre, les services métiers constituent le point de départ pour modéliser tous les processus et structures organisationnelles sous-jacents. Par conséquent, les services métiers sont parmi les éléments les plus importants de l’architecture d’entreprise.

Vue de la carte des processus métiers

Vue des processus métiers.

Cette vue peut être utilisée comme une « carte des processus » qui fournit un aperçu des processus métiers de l’organisation.

Vue de la coopération des processus métiers

Vue de la coopération des processus métiers.

Cette vue peut être utilisée, par exemple, pour modéliser des modèles d’exploitation.

Vue de la carte des acteurs métiers

Vue des acteurs métiers.

Les acteurs métiers peuvent être a) internes ou b) externes. Les acteurs métiers internes sont par exemple des unités organisationnelles, tandis que les acteurs métiers externes sont par exemple des clients, des partenaires commerciaux ou d’autres groupes de parties prenantes qui collaborent avec l’organisation (par exemple, des organisations du secteur public ou d’autres organismes de gouvernance).

Vue de la coopération des acteurs métiers

Vue de la coopération des acteurs métiers.

Deux cas d’utilisation sont les suivants :

1. Vue intra-entreprise : point de vue de coopération des acteurs métiers décrivant comment les acteurs métiers internes coopèrent et échangent des informations.
2. Vue inter-entreprise : point de vue d’écosystème dépeignant l’environnement d’exploitation dans lequel l’organisation opère. Un écosystème est un réseau d’organisations et de partenaires commerciaux qui collaborent à travers des interactions collaboratives. Il y a des fournisseurs, des sous-traitants et d’autres partenaires B2B, des clients, etc.

Vue des processus métiers

Vue des processus métiers.

Cette vue des processus métiers fournit une « structure et composition de haut niveau d’un ou plusieurs processus métiers (ou de leurs parties), où des services sont fournis, des acteurs sont attribués à des rôles, et l’information est utilisée par les processus métiers » [spécification ArchiMate 2.1]. Le diagramme de processus contient des éléments « Junction » utilisés pour modéliser les « fork » et les « join » dans les flux de processus.

Une vue de haut niveau des processus est présentée ci-dessous. Elle est basée sur le modèle d’exploitation dérivé du modèle d’affaires, comme indiqué dans le diagramme de flux de valeur ci-dessus.

Processus de l’idée à la production.

SIPOC (Fournisseurs, Entrées, Processus, Sorties, Clients)

SIPOC.

L’outil Six Sigma appelé SIPOC (Fournisseurs, Entrées, Processus, Sorties, Clients) peut être utilisé pour définir les éléments communs à tous les processus. Il s’agit d’un outil simple d’analyse des cas commerciaux : quelle valeur le client reçoit-il et comment la reçoit-il ?

Vue du processus métier avec les rôles métiers comme « couloirs » de processus – Approche en couches

Vue en couloirs du processus métier (modèle) 2.0.

« Rôle métier A » représente le client, tandis que le « couloir » supérieur représente le parcours du client.

Remarque ! Les étapes de processus (activités) sont imbriquées dans les rôles métiers (visualisés comme des « couloirs »), ce qui signifie : ces rôles métiers sont attribués à ces processus métiers/étapes de processus. Par conséquent, cette vue est une combinaison d’une vue du processus métier et d’une vue en couches.

La version ci-dessous illustre les flux d’information et de données (relations de flux). Le « couloir » supérieur représente le parcours du client (activités reliées par des relations de déclenchement).

Vue en couloirs du processus métier (modèle) 2.0 (flux d’information).

La version ci-dessous représente une approche de conception de service. Le « couloir » supérieur (Rôle A) représente le parcours du client, qui est connecté à l’organisation (Rôles B et C) à travers des services métiers (1 et 2).

Vue en couloirs du processus métier (modèle) 2.0 (services).

Vue en couches du processus métier

Vue en couches.

Cette vue peut être utilisée pour modéliser des processus métiers comprenant à la fois des étapes manuelles et automatisées.

Vue de la carte du parcours client

Lors de l’analyse des parcours clients à un niveau élevé, cette version est créée à l’aide d’éléments de motivation et de stratégie.

Carte du parcours client (niveau élevé).

Lors de l’analyse détaillée des parcours de service client, cette version est créée à l’aide d’éléments des couches métier et d’application (noyau).

Vue du parcours client (exemple) 1.0.

Cette vue centrée sur le client se concentre sur l’expérience client. Cette approche de développement « extérieur-intérieur » liée à la « conception de service » met en évidence l’aspect important selon lequel les services et produits sont conçus pour apporter de la valeur au client — et indirectement à l’organisation elle-même. Les parcours du client peuvent être utilisés pour visualiser les flux de valeur client qui s’étendent sur plusieurs services d’applications et applications.

Vue du plan de service

Vue du plan de service 1 (services et flux)

Cette vue est centrée sur le client et le service, mais elle met également en avant la partie « intérieure-extérieure » du service. Grâce à cette approche, le développement piloté par le service peut identifier les impacts potentiels sur le comportement et la structure des services à concevoir. Par conséquent, cette vue complète l’approche pilotée par l’expérience client à travers des aspects processus et fonctionnels.

Cette vue dispose de plusieurs variantes. L’exemple ci-dessus se concentre sur les flux d’information entre les couches et les éléments.

Vue des histoires d’utilisateur

Vue des histoires d’utilisateur.

Cette vue peut être utilisée pour visualiser les histoires d’utilisateur.

Vue des modèles de service cloud

Vue des modèles de service cloud.

Vue de l’information

Vue de l’information.

L’information peut être modélisée à différents niveaux d’abstraction comme suit : a) niveau conceptuel, b) niveau logique et c) niveau physique. La figure ci-dessus illustre ces niveaux d’abstraction.

Vue du modèle de données conceptuel

Vue du modèle de données conceptuel.

L’architecture de l’information de l’EA inclut les objets métiers utilisés dans les processus métiers, c’est-à-dire des concepts. Ces concepts et leurs relations peuvent être représentés dans un modèle de données conceptuel.

Concept « Service »

Concept service.

Le concept de service est souvent problématique et peut être compris de nombreuses façons différentes. Pour distinguer clairement les types de services impliqués, il est bon de mentionner le préfixe : service métier, service application ou service technologique. Selon ITIL, les services informatiques se rapportent aux services de production. Ainsi, les services informatiques correspondent le plus étroitement aux services application.

Service vs Produit

Vue Produit.

Le concept de produit peut être utilisé comme élément composite pour regrouper des services. Selon la spécification ArchiMate :

« Un produit représente une collection de services cohérents et/ou d’éléments de structure passifs, accompagnés d’un ensemble de contrats/accords, offerts en totalité aux clients (internes ou externes). »

« Un produit peut regrouper ou composer des services métier, des services application et des services technologiques, des objets métier, des objets données et des objets technologiques, ainsi que des contrats. Ainsi, un produit peut regrouper ou composer des éléments provenant de couches autres que la couche métier. »

« Une valeur peut être associée à un produit. Le nom du produit est généralement le nom utilisé dans la communication avec les clients, ou il peut s’agir d’un nom plus générique (par exemple, « assurance voyage »). »

Point de vue Application

Vue de la couche architecture application.

Vue carte des services application

Vue des services application.

Vue carte des applications

Vue carte des applications.

Portefeuille d’applications, où les applications peuvent être regroupées par unité métier.

Vue de coopération application (flux de données)

Vue de coopération application.

Vue d’intégration application (relations dynamiques)

Plusieurs façons alternatives de modéliser le transfert de données entre applications sont illustrées dans l’exemple ci-dessous (1 à 10).

• « Application A » possède l’objet de données « A-1 » demandé par « Application B ».
• Les données circulent de « Application A » vers « Application B ».
• « Application A » réalise le service « A-1 » utilisé par « Application B ».
• En pratique, « Application B » demande l’interface application « A-1 » et reçoit une réponse…

Vue d’intégration application.

Vue de structure application

Cette vue aide à concevoir ou à comprendre la structure principale d’une application et de ses sous-composants ainsi que des données associées. Le diagramme peut être utilisé pour décomposer la structure du système d’application en cours de construction afin d’illustrer la modularité/décomposition : quels sont les sous-systèmes/sous-composants, quels services application (ou interfaces application) fournissent-ils.

Vue de la structure de l’application.

Notez que les services d’application (figure du haut) sont des fonctionnalités comportementales fournies par des interfaces structurelles (GUI et/ou API dans la figure du bas). Les services d’application et les interfaces d’application sont « deux faces d’une même pièce ».

Vue de la structure de l’application 2.

Vue de l’architecture de l’application

Cette vue combine des approches au niveau EA et au niveau solution, car à la fois les applications et les modules d’application existent dans la même vue.

Architecture de l’application.

Modèle de composants d’application (CM)

Le modèle de composants d’application 0-n est une méthode de modélisation de l’architecture d’application composée de diagrammes à différents niveaux d’abstraction comme suit :

• Au niveau CM-0, le diagramme décrit comment l’application cible interagit avec son environnement et quelles interactions existent avec les applications adjacentes et les utilisateurs. L’application cible est décrite comme une boîte noire.
• Au niveau CM-1, l’application cible est décomposée en modules (composants principaux), et les services d’application (ou interfaces d’application) qu’ils fournissent et exigent. L’application cible est décrite comme une boîte blanche.
• Au niveau CM-2, les modules sont décomposés en sous-composants. (Le nombre de niveaux nécessaires dépend de la situation.)

Le diagramme du modèle de composants d’application (CM) ci-dessous comprend des composants d’application et des services d’application. En alternative, les interfaces d’application peuvent être utilisées à la place des services d’application, selon la situation. Comme toujours, il est important d’utiliser un style de modélisation adapté à l’objectif et de ne modéliser que les éléments qui apportent des informations suffisantes et de la valeur. Cela dépend du concepteur — s’il préfère mettre l’accent sur les aspects fonctionnels ou être plus précis et modéliser par exemple des interfaces réelles avec des noms précis.

Le diagramme du modèle de composants ci-dessous comprend des composants d’application et des services d’application. En alternative, les interfaces d’application peuvent être utilisées à la place des services d’application.

Modèle de composants d’application – 0 (CM-0)

Modèle de composants d’application – 0.

Niveau du modèle de composants – 0 (CM-0) (ci-dessus) illustre l’interaction entre l’application cible et les applications adjacentes. Tous les services d’application pertinents (ou interfaces d’application) sont introduits. Le diagramme de niveau 0 comprend des composants de couche d’architecture d’entreprise et leurs services, avec l’application cible au centre.

Modèle de composants d’application – 1 (CM-1)

Modèle de composants d’application – 1.

Niveau du modèle de composants – 1 (CM-1) (ci-dessus) illustre comment l’application cible est décomposée en modules (ou composants principaux), et quels services d’application (ou interfaces d’application) chaque module réalise. Notez ! Les applications externes peuvent être exclues de ce niveau, mais leurs services (ou interfaces) sont affichés. Lorsqu’on montre des éléments de niveau inférieur, certains éléments de niveau supérieur peuvent/ont besoin d’être omis – pour simplifier : gardez le diagramme lisible.

Modèle de composants d’application – 2 (CM-2)

Modèle de composants d’application – 2.

Niveau du modèle de composants – 2 (CM-2) (ci-dessus) illustre comment les modules de l’application cible sont composés de sous-composants et comment ils interagissent.

Vue des fonctions de l’application

Décomposition des fonctions de l’application : quelles fonctions contient le système et quels services d’application fournit-il ?

Vue des fonctions de l’application.

Vue des processus de l’application

Vue des processus de l’application.

Vue des processus de l’application – imbriquage.

Vue des processus de l’application – internes.

Vue du diagramme de séquence de composants d’application

Les diagrammes de séquence ne sont pas entièrement dans le cadre d’ArchiMate, mais dans celui de UML. Toutefois, nous pouvons modéliser, par exemple, la séquence des actions entreprises par les composants d’application à l’aide d’ArchiMate, comme indiqué ci-dessous.

Vue de séquence d’application.

Les relations dynamiques « Déclencheur » et « Flux » peuvent être utilisées pour modéliser les dynamiques entre les composants d’application. La disposition de cette vue peut ressembler au positionnement d’un diagramme de séquence UML.

Vue du diagramme de séquence de composant d’application 2

Cette version (ci-dessous) illustre comment ArchiMate peut être utilisé pour modéliser la séquence des actions entreprises par les parties internes des composants d’application. Les parties internes sont par exemple a) des processus ou fonctions comportementaux et b) des sous-composants structurels. Ces éléments sont modélisés à l’aide des éléments Processus d’application, Fonction d’application et Composant d’application. Ils sont présentés ici uniquement comme des alternatives.

Vue de séquence d’application (2).

Le flux d’opérations dans ce diagramme de séquence (ci-dessus) :

1. Le sous-processus « X » du composant d’application « A » envoie un message de demande avec le paramètre « A » à l’application B.
2. Le sous-processus « B-1 » du composant d’application « B » reçoit la requête entrante, puis (de manière synchrone) appelle le composant d’application C, où la fonction d’application « Y » reçoit la requête, effectue certaines opérations et répond.
3. Un autre sous-processus « B-2 » du composant d’application « B » envoie un message avec des paramètres au composant d’application D et reçoit une confirmation. Le composant d’application « D » contient des sous-composants qui effectuent des traitements.
4. Le composant d’application « A » reçoit un message de réponse du composant d’application B.

Comme indiqué ici, nous pouvons modéliser des cas d’intégration assez complexes en combinant ces éléments (composants d’application, processus d’application et fonctions d’application ainsi que les relations (Déclencheur, Flux)). Les diagrammes de séquence UML ont leur utilisation spécialisée dans la conception logicielle, mais ArchiMate peut être utilisé pour de nombreuses finalités de modélisation – y compris la conception d’applications.

L’intégration des applications est l’une des parties les plus importantes de l’architecture d’entreprise (EA). C’est pourquoi il est avantageux de pouvoir modéliser en détail comment les applications échangent des données et quelles mécanismes d’interaction sont utilisés. Une bonne ressource pour une compréhension approfondie des modèles d’intégration est le livre « Enterprise Integration Patterns », voici le lien.

La séquence d’utilisateur finale ajoutée (ci-dessous) suit la même idée d’utiliser les relations dynamiques ArchiMate Déclencheur et Flux, qui peuvent être utilisées pour modéliser les modèles de messagerie synchrones et asynchrones (requête-réponse et rappel, ainsi que publication-abonnement, etc.).

Vue du modèle de séquence.

Vue du processus ETL

Vue du processus ETL.

Vue EAI / ESB

Vue du modèle EAI – ESB.

Vue en couches

Vue en couches.

La vue en couches peut être utilisée comme diagramme contextuel de synthèse de la zone cible. Le principal avantage de cette vue est de montrer l’utilisation des applications dans les processus métiers et les services qu’elles fournissent. La figure ci-dessus utilise l’élément de regroupement ArchiMate pour modéliser différentes couches, tandis que la figure ci-dessous utilise l’élément de groupe visuel fourni par l’outil (Archi).

Dans ArchiMate, il existe fondamentalement trois couches : 1) la couche métier, 2) la couche application et 3) la couche technologie. Leurs couleurs sont généralement les suivantes : la couche métier est jaune, la couche application est turquoise, la couche technologie est verte (voir le cadre fondamental ArchiMate, lien).

Vue en couches.

Vue des applications et des bases de données

Les bases de données constituent une unité significative dans l’architecture d’entreprise globale d’une organisation. Par exemple, « base de données client » ou « base de données client », « base de données produit », etc. Alternativement, une base de données peut être constituée de toutes les tables d’une application (par exemple, « table client », « table commande », « table facture », etc.), qui ensemble forment une seule base de données. Selon la spécification ArchiMate, l’objet de données peut être utilisé pour modéliser des bases de données logiques (figure ci-dessous), le chapitre 9.4.1 « Objet de données » indique : « Les exemples typiques d’objets de données sont les enregistrements clients, les bases de données clients ou les réclamations d’assurance. » « Une exception importante concerne le cas où un objet de données est utilisé pour modéliser une collection de données, telle qu’une base de données, où un seul exemplaire existe. » ArchiMate dispose d’un mécanisme intégré élégant qui permet à certains concepts d’être utilisés à différents niveaux d’abstraction (et de détail). Ainsi, par exemple, l’objet de données peut être utilisé pour modéliser des bases de données logiques, des tables de base de données, des structures de messages (échangées entre applications), etc.

Considérations relatives à la modélisation des bases de données.

Base de données en tant que composant d’application.

Niveaux d’abstraction des bases de données.

Vue du modèle de données.

Vue des cas d’utilisation

ArchiMate peut être utilisé pour analyser les cas d’utilisation du point de vue fonctionnel des applications. Les cas d’utilisation (connus dans UML) peuvent être mappés aux services d’application, comme indiqué dans la figure ci-dessous.

Vue des cas d’utilisation (modèle 1).

Les cas d’utilisation peuvent être divisés en : a) cas d’utilisation métier et b) cas d’utilisation système (également appelés cas d’utilisation système). La figure ci-dessous illustre comment les « cas d’utilisation principaux » sont modélisés comme services métier, et les cas système ultérieurs comme services d’application.

Vue des cas d’utilisation (exemple).

Lorsque les cas d’utilisation sont identifiés comme services d’application, ils peuvent être utilisés ultérieurement comme éléments fonctionnels des applications cibles dans d’autres diagrammes (par exemple, dans les vues en couches). Autrement dit : les services d’application représentent le comportement (fonctionnalité) des applications. Pour plus d’informations détaillées sur l’analyse des cas d’utilisation, voir le cookbook ArchiMate,lien.

Point de vue technologique

Vue de la couche d’architecture technologique.

Vue de l’infrastructure

Cette vue représente la plateforme des applications. Ce modèle peut être utilisé pour modéliser la configuration de l’environnement d’exécution et le déploiement des applications métier.

Vue de l’infrastructure.

Vue de l’infrastructure (imbriquée).

Vue de la couche de mise en œuvre et de migration / Vue de la couche d’architecture de transition

Vue du plan d’implémentation

Vue du plan d’implémentation.

Vue du tableau Kanban

Tableau Kanban (EA).

Kanban peut être utilisé pour visualiser le travail et le flux de travail. Kanban montre par exemple comment les exigences de développement, les épics, les histoires utilisateur, etc., passent du backlog à l’état prêt (terminé). Kanban peut être appliqué à divers usages selon l’échelle et la portée du cas de développement. Par exemple, les « épics » peuvent être utilisés au niveau EA, ou les « histoires utilisateur » ou les « exigences » au niveau du projet. La granularité des éléments de travail peut varier selon la situation.

Vue générique

Vue générique.

Cette vue simplifiée peut être utilisée, par exemple, comme diagramme de contexte pour un service, un programme ou un projet spécifique.

Fonctionnalités supplémentaires

Aperçu du contexte – Carte de la Voie lactée

Il s’agit d’une approche permettant de visualiser le maximum d’éléments dans la même vue. Pour plus de détails, voir la Carte de la Voie lactée pour ArchiMate,lien.

FM Carte de la Voie lactée (Niveau 2). (Remarque ! Ce schéma de couleurs utilise les couleurs par défaut d’ArchiMate. D’autres couleurs peuvent être utilisées selon les besoins.)

Vue de la coopération

Les couches peuvent être combinées comme indiqué dans l’exemple de diagramme de flux de données ci-dessous.

Vue de la coopération des applications (étendue).

Métamodèle

Métamodèle.