L’étude de cas ArchiSurance est un exemple fictif créé pour illustrer l’utilisation du langage de modélisation ArchiMate® dans le cadre TOGAF®. L’étude porte sur la compagnie d’assurance ArchiSurance, formée par la fusion de trois entreprises auparavant indépendantes. L’étude décrit l’architecture de base de l’entreprise, suivie de plusieurs scénarios de changement.

Cette étude de cas est obligatoire comme exemple dans les formations certifiées ArchiMate. Toutefois, elle ne fait pas partie de la définition officielle de TOGAF. Ce travail soutient la vision du groupe The Open Group en matière de flux d’information sans frontières en démontrant l’utilisation combinée des normes TOGAF et ArchiMate, permettant une représentation cohérente des informations d’architecture à travers différentes organisations, systèmes et programmes.

Introduction

Cette étude de cas fictive illustre l’utilisation pratique du langage de modélisation d’entreprise ArchiMate dans le cadre TOGAF. L’étude porte sur la compagnie d’assurance ArchiSurance, issue de la fusion de trois entreprises auparavant indépendantes opérant dans différentes zones métropolitaines.

Cette étude de cas est utilisée comme exemple tout au long des formations certifiées ArchiMate et sert de matière de fond pour l’examen de certification ArchiMate. Elle commence par l’architecture de base des activités, applications, données et technologies, en utilisant des points de vue ArchiMate ou TOGAF appropriés. L’étude poursuit ensuite avec deux scénarios de changement. Le premier scénario fournit des exemples de vues illustrant les cycles de développement et de mise en œuvre de l’architecture TOGAF. Il montre la vision architecturale, les objectifs commerciaux, les principes et exigences, l’architecture cible des activités, applications, données et technologies, les résultats de l’analyse des écarts entre l’architecture de base et l’architecture cible, ainsi que les vues soutenant la planification de mise en œuvre et de migration. Dans le second scénario, l’état cible du premier scénario est pris comme nouvelle architecture de base, et les clients peuvent accéder directement à leur portefeuille d’assurance via le web. Aucun modèle n’est actuellement disponible pour ce scénario.

Le groupe The Open Group s’attend à ce que l’étude de cas évolue au fil du temps et encourage ses membres à ajouter de nouveaux aspects et vues ou à créer de nouveaux scénarios de changement, à condition qu’ils restent cohérents avec la description initiale de l’étude et les modèles existants.

TOGAF® et ArchiMate®

Les cadres d’architecture d’entreprise couvrent différents aspects qui soutiennent les architectes d’entreprise. Parmi d’autres, ils peuvent contenir toute combinaison des éléments suivants :

• Un processus de création d’architecture (« manière de travailler »)
• Une collection ou une classification de points de vue
• Un langage pour décrire l’architecture (définissant les concepts et les relations, ainsi que la notation)

Le groupe The Open Group maintient deux normes ouvertes pour l’architecture d’entreprise : TOGAF [1] et ArchiMate [2].

Le cœur de TOGAF est le processus de développement et de mise en œuvre de l’architecture d’entreprise — la Méthode de développement d’architecture (ADM). TOGAF décrit également des points de vue, des techniques, des modèles de référence et un cadre de contenu pour identifier les types de blocs de construction qui composent les architectures. Toutefois, TOGAF ne prescrit pas l’utilisation d’un langage de modélisation spécifique pour créer des vues architecturales.

ArchiMate est un langage graphique qui fournit une représentation uniforme des modèles pour soutenir l’ensemble du cycle de développement d’architecture. La version 2.0 de la norme inclut un langage central destiné à décrire les architectures réelles (architectures commerciales, systèmes d’information et technologies, ainsi que les relations entre elles), ainsi que des extensions pour modéliser la motivation architecturale, ainsi que la planification de mise en œuvre et de migration. La figure 1 décrit la manière dont le langage central et les extensions sont liés à l’ADM TOGAF. En plus de définir des concepts et relations de modélisation, ArchiMate — tout comme TOGAF — définit un ensemble de points de vue architecturaux.

Figure 1 : Correspondance entre ArchiMate et TOGAF

TOGAF et ArchiMate ont une base commune solide dans leur philosophie et leur utilisation des points de vue pour capturer et communiquer différents aspects d’un modèle d’architecture sous-jacent unique. Les normes se complètent car TOGAF se concentre sur le processus de développement et de mise en œuvre des architectures, tandis qu’ArchiMate se concentre sur un langage uniforme pour modéliser les artefacts architecturaux.

Le langage ArchiMate, tel qu’il est décrit dans la norme technique [2], complète TOGAF [1] en fournissant un ensemble de concepts et de relations indépendant du fournisseur, incluant une notation graphique, afin d’aider à créer des modèles cohérents et intégrés pouvant être représentés sous forme de vues.

Contexte

ArchiSurance [3,4] est le résultat d’une fusion récente de trois compagnies d’assurance auparavant indépendantes :

• Home & Away, spécialisée dans les assurances habitation et voyage
• PRO-FIT, spécialisée dans les assurances automobiles
• Legally Yours, spécialisée dans les assurances des frais juridiques

L’entreprise se compose désormais de trois divisions portant les mêmes noms et sièges sociaux que leurs prédécesseurs indépendants.

Figure 2 : ArchiSurance : Résultat de la fusion de trois compagnies d’assurance

ArchiSurance a été formée pour exploiter de nombreux synergies entre les trois organisations. Bien que les trois compagnies pré-merger vendent des types d’assurance différents, leurs modèles commerciaux étaient similaires. Les trois produits étaient vendus directement aux consommateurs et aux petites entreprises via des canaux web, e-mail, téléphone et postal. Bien que siégeant dans des villes différentes, chacune était entièrement installée dans un immeuble de bureau moderne dans une zone métropolitaine. Chaque entreprise disposait d’une base de clients fidèles et bénéficiait d’une bonne réputation en matière d’intégrité, de valeur, de service et de stabilité financière. Les trois entreprises étaient toutes détenues en privé par des chaînes d’investisseurs institutionnels et individuels.

Les principaux investisseurs des trois entreprises ont lancé des négociations de fusion après avoir constaté l’entrée de concurrents à faible coût sur leurs marchés, de nouvelles opportunités dans des régions à fort potentiel de croissance, et la nécessité d’un investissement important en nouvelles technologies pour chacune des entreprises afin de rester compétitives. Ils ont réalisé que seule une entreprise fusionnée plus grande pouvait simultanément maîtriser les coûts, maintenir la satisfaction des clients, investir dans de nouvelles technologies et exploiter les marchés émergents à fort potentiel de croissance. Les négociations de fusion et l’approbation réglementaire ont pris 18 mois, mais les documents ont été signés il y a deux ans et la fusion a été achevée.

La nouvelle entreprise propose tous les produits d’assurance des trois compagnies pré-merger et entend ajuster fréquemment ses offres en fonction des évolutions du marché. Comme ses trois prédécesseurs, ArchiSurance vend directement aux clients via l’imprimé, le web et le marketing direct.

La fusion a posé de nombreux défis d’intégration et de coordination pour les processus métiers et les systèmes d’information de la nouvelle entreprise. Ces défis sont manifestes dans l’architecture de base des activités, applications, données et technologies d’ArchiSurance. Mais avant tout, la phase préliminaire de l’ADM TOGAF a établi le contexte motivant de ces défis.

Phase préliminaire

Pour guider ses évolutions futures en matière d’entreprise et de technologies de l’information, ArchiSurance a décidé de développer une architecture d’entreprise fondée sur TOGAF 9.1 et ArchiMate 2.0, avec une adaptation minimale.

Dans le cadre de la phase préliminaire, les principaux intervenants dans l’engagement architectural et leurs préoccupations ont été identifiés (modélisés dans ArchiMate comme des moteurs internes). TOGAF définit une matrice de cartographie des intervenants pour représenter cela. Dans ArchiMate, cela peut être exprimé à l’aide du point de vue des intervenants :

Le point de vue des intervenants permet à l’analyste de modéliser les intervenants, leurs préoccupations et les évaluations relatives à celles-ci (en termes de forces, faiblesses, opportunités et menaces). En outre, il est possible d’associer ces préoccupations et évaluations à des objectifs initiaux (de haut niveau) afin de les résoudre.

La figure 3 montre un fragment de ce type de diagramme, identifiant deux intervenants (le comité d’architecture et ses clients actuels et potentiels) et leurs préoccupations, modélisées comme des moteurs. La satisfaction du client est une préoccupation commune aux deux intervenants. La satisfaction des intervenants peut être affinée en préoccupations plus détaillées ; par exemple, le profit.

Figure 3 : Fragment du point de vue des intervenants

Les moteurs conduisent au développement d’objectifs commerciaux spécifiques, comme illustré ci-dessous pour atteindre le profit. Des objectifs tels que la réduction des coûts peuvent être décomposés en réduction des coûts de maintenance et en réduction des coûts de personnel.

Figure 4 : Objectifs commerciaux conduisant au profit

ArchiMate définit les principes comme des propriétés normatives de tous les systèmes dans un contexte donné, ou de la manière dont ils sont réalisés. Notez que le terme « système » inclut ici les organisations et les unités organisationnelles, et non seulement les systèmes informatiques. Ainsi, les principes aident à réaliser les objectifs commerciaux. TOGAF définit les principes comme des énoncés qualitatifs d’intention que l’architecture doit respecter. Un principe doit être soutenu par une justification et avoir une implication importante.

Le point de vue des principes ArchiMate (un exemple présenté à la figure 5) décrit graphiquement les principes, leurs dépendances et les objectifs qu’ils réalisent :

Le point de vue des principes permet à l’analyste ou au concepteur de modéliser les principes pertinents pour le problème de conception en cours, y compris les objectifs qui motivent ces principes. En outre, les relations entre les principes et les objectifs peuvent être modélisées. Par exemple, les principes peuvent influencer positivement ou négativement les uns les autres.

Figure 5 : Point de vue des principes

TOGAF définit un catalogue de principes pour offrir un aperçu des principes.

Phase B : Architecture commerciale de base

Après la fusion, ArchiSurance a mis en place un front office partagé en tant que centre d’assistance multicanal pour les ventes et le service client, dont le centre principal est situé au siège précédent de Home & Away. Trois bureaux arrière distincts continuent de gérer les produits d’assurance des trois entreprises initiales. Un centre de services partagés (SSC) pour le traitement des documents a été établi au siège précédent rentable. Ce centre gère le dépôt central de documents et tous les flux de documents automatisés. En outre, il effectue toutes les opérations de numérisation, d’impression et d’archivage lorsque des documents contraignants entrent ou sortent d’ArchiSurance. Pour assurer la continuité de l’activité et gérer les pics d’activité, le SSC est également équipé de personnel formé et d’équipements permettant d’effectuer des fonctions de front office, et le front office est également préparé en conséquence.

Figure 6 : Structure organisationnelle globale d’ArchiSurance

Dans la phase B (architecture commerciale) du cadre TOGAF ADM, ArchiMate peut exprimer et relier la structure organisationnelle, les produits, les services, les fonctions, les processus et les informations d’ArchiSurance. L’architecture commerciale fournit un contexte pour les architectures des données, des applications et des technologies.

Structure organisationnelle

Pour décrire la structure organisationnelle, ArchiMate définit le point de vue Organisation :

Le point de vue Organisation se concentre sur l’organisation (interne) d’une entreprise, d’un département, d’un réseau commercial ou d’une autre entité organisationnelle. Dans ce point de vue, les modèles peuvent être représentés sous forme de diagrammes de boîtes imbriquées, mais des représentations plus traditionnelles telles que les organigrammes peuvent également être utilisées. Le point de vue Organisation est très utile pour identifier les capacités, l’autorité et la responsabilité au sein d’une organisation.

L’équivalent TOGAF de ce point de vue est le diagramme de décomposition organisationnelle.

La structure organisationnelle est généralement représentée sous forme d’arbre, comme indiqué à la figure 7, bien que les méthodes de décomposition organisationnelle utilisées dans ArchiMate et TOGAF offrent plus d’options que les simples organigrammes en arbre. Cette vue montre la structure organisationnelle de haut niveau d’ArchiSurance, ainsi que ses principales localisations et divisions. En alternative, un diagramme imbriqué pourrait subdiviser l’organisation par localisation et division.

Figure 7 : Vue organisationnelle

Fonctions commerciales

Les fonctions commerciales ArchiMate regroupent le comportement selon un ensemble sélectionné de critères (généralement des ressources commerciales requises et/ou des compétences).

Les principales fonctions commerciales identifiées par ArchiSurance sont :

• Marketing — recherche, planification, promotion et gestion des produits et des segments, et collaboration avec les actuaires pour concevoir des produits
• Actuaire — détermination des prix des produits et des niveaux de réserves, collaboration avec le marketing pour concevoir de nouveaux produits, et analyse du risque de l’entreprise
• Relations clients — interactions entre ArchiSurance et ses clients ; gestion des questions des clients, enregistrement des réclamations reçues, et réalisation de campagnes de marketing direct
• Souscription — fixation des prix pour les polices individuelles et émission de propositions d’assurance et de polices
• Réclamations — formulation et exécution de la réponse d’ArchiSurance à chaque réclamation déposée contre ses polices
• Finance — collecte périodique des primes auprès des clients conformément aux contrats et traitement des paiements des sinistres
• Traitement des documents — soutien des autres fonctions par numérisation, impression et archivage de documents
• Gestion des investissements — gestion des actifs financiers et immobiliers afin d’obtenir un rendement maximal dans les limites de liquidité et de risque imposées par l’entreprise et la réglementation

Certaines de ces fonctions commerciales sont répliquées dans les services administratifs des trois divisions d’ArchiSurance.

Pour modéliser les fonctions commerciales et leurs relations, ArchiMate définit le point de vue Fonction commerciale :

Le point de vue Fonction commerciale montre les principales fonctions commerciales d’une organisation et leurs relations en termes de flux d’information, de flux de valeur ou de flux de biens.

L’équivalent TOGAF de ce point de vue est le diagramme de décomposition des fonctions.

La figure 8 montre les principales fonctions commerciales d’ArchiSurance, ainsi que les flux d’information les plus importants entre les fonctions et les rôles externes. Elle montre également la réplication des fonctions commerciales dans les services administratifs des différentes divisions.

Figure 8 : Vue Fonction commerciale

Processus commerciaux

Les processus commerciaux ArchiMate regroupent le comportement selon l’ordre des activités. Ils produisent un ensemble défini de produits ou de services. L’architecture des processus montre les principaux processus commerciaux et leurs relations, pouvant également indiquer les étapes principales de chaque processus. Elle ne montre généralement pas tous les détails du flux de processus — c’est l’objectif des langages de modélisation des processus commerciaux. ArchiMate définit un point de vue Processus commercial :

Le point de vue Processus commercial est utilisé pour montrer la structure et la composition de haut niveau d’un ou plusieurs processus commerciaux (ou de leurs parties).

L’équivalent TOGAF de ce point de vue est le diagramme de processus.

La figure 9 montre deux processus commerciaux clés d’ArchiSurance et leurs sous-processus de haut niveau : Clôture du contrat (exécuté lors de la vente d’un nouveau produit d’assurance) et Traitement du sinistre (exécuté lors de la réception d’une réclamation pour dommage). Bien que les détails de ces processus puissent varier selon les types de produits d’assurance, les étapes principales restent les mêmes.

Figure 9 : Vue Processus commercial

Phase C : Architecture de base des systèmes d’information (Applications)

Depuis la fusion, les trois divisions ont adopté un portail commun, une suite logicielle de centre d’appels et un système de gestion de documents. En outre, l’entreprise a choisi une solution CRM stratégique et l’a mise en œuvre pour Home & Away et PRO-FIT. Toutefois, comme la direction s’est concentrée sur la réduction du risque post-fusion tout en améliorant continuellement les performances quotidiennes de chaque division, la rationalisation des applications commerciales clés n’a pas encore commencé. Maintenant qu’ArchiSurance a atteint les attentes de performance post-fusion, les investisseurs s’attendent à des économies substantielles sur les coûts informatiques grâce à l’adoption d’un ensemble commun de produits et d’applications centrées sur le client. Des défis subsistent. Home & Away continue d’utiliser son package d’application de gestion des contrats et de la finance pré-fusion, tandis que PRO-FIT et Legally Yours utilisent encore leurs propres applications personnalisées pré-fusion.

Figure 10 : Environnement des applications

Coopération entre applications

ArchiMate définit un point de vue Coopération entre applications pour offrir une vue d’ensemble du paysage des applications et des dépendances entre elles :

Le point de vue Coopération entre applications décrit les relations entre les composants d’application, c’est-à-dire les flux d’information entre eux, ou les services qu’ils fournissent et utilisent. Ce point de vue est généralement utilisé pour créer une vue d’ensemble du paysage des applications d’une organisation. Il est également utilisé pour exprimer la coopération (interne) ou l’orchestration des services qui, ensemble, soutiennent l’exécution des processus commerciaux.

L’équivalent TOGAF de ce point de vue est le diagramme de communication des applications.

La figure 11 montre les principales applications d’ArchiSurance et les principaux flux de données entre les applications.

Figure 11 : Vue Coopération entre applications

Alignement entre processus et applications

TOGAF ne définit pas de diagrammes pour l’alignement entre processus et applications. Toutefois, il précise des points de vue basés sur des matrices pour montrer les liens entre l’architecture commerciale et l’architecture des applications ; par exemple, la matrice Application/Organisation et la matrice Application/Fonction.

Les relations entre les composants d’application peuvent également être modélisées graphiquement. ArchiMate définit le point de vue Utilisation des applications :

Le point de vue Utilisation des applications décrit comment les applications sont utilisées pour soutenir un ou plusieurs processus commerciaux, et comment elles sont utilisées par d’autres applications. Il peut être utilisé pour concevoir des applications en identifiant les services requis par les processus commerciaux et d’autres applications, ou pour concevoir des processus commerciaux en décrivant les services disponibles. En outre, comme il identifie les dépendances des processus commerciaux vis-à-vis des applications, il peut être utile pour les gestionnaires opérationnels responsables de ces processus.

Le concept de service d’application joue un rôle central dans ce point de vue. La figure 12 montre un sous-ensemble des services fournis par les applications utilisées par la division Home & Away d’ArchiSurance, et indique quels sous-processus du processus de traitement des sinistres utilisent quels de ces services.

Figure 12 : Vue Utilisation des applications

Phase C : Architecture de base des systèmes d’information (données)

L’architecture des données d’ArchiSurance décrit les principales relations entre ses objets métiers conceptuels et ses objets logiques de données. ArchiMate définit le point de vue sur la structure d’information à cet effet :

Le point de vue sur la structure d’information est comparable aux modèles d’information traditionnels créés dans presque tout processus de développement de système d’information. Il montre la structure de l’information utilisée dans l’entreprise ou dans des processus métiers ou applications spécifiques sous la forme de types de données ou de structures de classes (orientées objet).

L’un des points de vue sur les données définis par TOGAF est le diagramme de données logiques.

La figure 13 montre un sous-ensemble des objets métiers définis par ArchiSurance. Une partie des informations clients est le dossier d’assurance, composé de demandes d’assurance, de contrats d’assurance et de sinistres. De nombreuses spécialisations de l’objet contrat d’assurance sont définies, une pour chaque type d’assurance vendu par ArchiSurance.

Figure 13 : Vue de la structure d’information

Un autre point de vue sur les données défini par TOGAF est le diagramme de diffusion des données :

Le but du diagramme de diffusion des données est de montrer les relations entre les entités de données, les services métiers et les composants d’application. Le diagramme montre comment les composants d’application réalisent physiquement des entités logiques. Cela permet une dimensionnement et une optimisation efficaces de la surface informatique. En outre, en attribuant une valeur métier aux données, on peut obtenir une indication de la criticité métier des composants d’application.

La figure 14 montre un diagramme de diffusion des données pour une application ArchiSurance.

Figure 14 : Diagramme de diffusion des données

Phase D : Architecture technologique de base

La figure 15 présente le paysage de l’infrastructure technologique d’ArchiSurance. Dans le bureau avant, situé au siège social de Home & Away, il y a un serveur commun et un serveur dédié à l’hébergement web. Le centre de services partagés (SSC), situé au siège social de PRO-FIT, dispose de son propre serveur de gestion de fichiers. Chacun des trois bureaux arrière dispose d’un serveur pour ses applications.

Les réseaux locaux (LAN) relient les serveurs et les ordinateurs personnels des trois sites ArchiSurance, qui sont eux-mêmes reliés par le réseau étendu d’entreprise (WAN).

Figure 15 : Paysage de l’infrastructure

Pour une vue d’ensemble du paysage de l’infrastructure, ArchiMate définit le point de vue sur l’infrastructure :

Le point de vue sur l’infrastructure comprend les éléments matériels et logiciels de l’infrastructure qui soutiennent la couche d’application, tels que les dispositifs physiques, les réseaux ou les logiciels système (par exemple, systèmes d’exploitation, bases de données et logiciels intermédiaires).

L’équivalent TOGAF de ce point de vue est le diagramme des environnements et emplacements.

La figure 16 montre les principaux composants d’infrastructure d’ArchiSurance regroupés par emplacement et division. Cette vue montre également les réseaux reliant différents dispositifs ainsi que les artefacts (d’applications) déployés sur ces dispositifs.

Figure 16 : Vue de l’infrastructure

Scénarios de changement

Scénario 1 : Rationalisation du portefeuille d’applications

L’inflexibilité de l’architecture des applications d’ArchiSurance rend difficile l’adaptation aux conditions commerciales changeantes. En partie à cause de la fusion, l’environnement d’application est devenu fragmenté, entraînant une redondance de données et un chevauchement fonctionnel, ainsi qu’une intégration point à point des applications utilisant divers formats et méthodes de données. Ces problèmes entraînent une instabilité interne, une augmentation des coûts de maintenance des applications, et entravent le partage d’informations au sein de l’entreprise et avec les partenaires. En conséquence, le service informatique dispose d’un important retard de demandes de travail. La direction supérieure d’ArchiSurance est très préoccupée par ce retard, en particulier par l’impossibilité de partager automatiquement des informations avec un grand nombre de partenaires commerciaux contractuels et d’agents d’assurance influents.

Ce scénario rationalise le portefeuille d’applications d’ArchiSurance en :

• Migration vers une suite de back-office intégrée qui assure des fonctions telles que la gestion des contrats et les opérations financières. La suite comprendra :
  • Un système automatisé de souscription qui génère des propositions et des contrats — AUTO-U
  • Un système de gestion des contrats préconfiguré, intégré au système automatisé de souscription, pour émettre, modifier et renouveler les contrats ; ce système gère également la comptabilité et la facturation des clients — P-ADMIN
  • Un système de gestion des sinistres préconfiguré, avec écrans et flux de travail configurables pour soutenir les trois lignes d’activité d’ArchiSurance — VERSA-CLAIM
  • Un gestionnaire de configuration des produits pour définir tous les produits d’assurance et exposer ces définitions via des services web à AUTO-U, P-ADMIN et VERSA-CLAIM — P-CONFIG
  • Un système de gestion des règles métier (BRMS) composé d’un référentiel de règles, d’un moteur de traitement, d’un environnement de développement des règles et d’outils d’écriture pour l’interface utilisateur de gestion des règles. Le moteur de règles met à disposition la fonctionnalité d’exécution des règles via des services web à AUTO-U, P-ADMIN, VERSA-CLAIM et P-CONFIG — EDGE
• Finalisation de la migration vers le système CRM stratégique

L’investisseur principal et le PDG d’ArchiSurance soutiennent ces plans à condition que les clients et partenaires d’ArchiSurance ne voient aucune modification. Les produits et services de l’assureur ne doivent pas être affectés, et toutes les interactions avec les clients et partenaires doivent se dérouler sans interruption.

Figure 17 : Rationalisation du portefeuille des applications

Dans le cadre de cette initiative, l’infrastructure technique sera également simplifiée. Les serveurs back-office séparés seront remplacés par un cluster de serveurs partagés situé au centre de données du siège social de Home & Away. Toutefois, afin de garantir la continuité de l’activité, un cluster de serveurs de secours sera également installé au centre de données du siège social de PRO-FIT.

Phase A : Vision architecturale

La phase A du cycle ADM TOGAF établit le travail architecturale en définissant le périmètre, les contraintes et les objectifs, et lance l’itération du cycle de développement architecturale. Cette phase valide également le contexte métier et établit l’énoncé du travail architecturale.

Le contexte métier se compose de besoins commerciaux clés fondés sur les objectifs commerciaux principaux et les principes architecturaux. La figure 18 montre certains objectifs commerciaux et principes pertinents pour la situation actuelle.

Figure 18 : Objectifs et principes commerciaux

Les objectifs et principes constituent la base des exigences concrètes, comme illustré dans le point de vue ArchiMate de raffinement des objectifs :

Le point de vue de raffinement des objectifs permet au concepteur de modéliser le raffinement des objectifs (de haut niveau) en objectifs plus concrets, et des objectifs concrets en exigences ou contraintes qui décrivent les propriétés nécessaires pour réaliser les objectifs. Les relations d’agrégation sont utilisées pour raffiner les objectifs en sous-objectifs. Les relations de réalisation sont utilisées pour modéliser le raffinement des objectifs en exigences.

La figure 19 montre un exemple de ce point de vue pour la situation actuelle de changement.

Figure 19 : Vue de raffinement des objectifs

Un élément important de la vision architecturale est une représentation de haut niveau de l’architecture de référence et de l’architecture cible, afin d’expliquer la valeur ajoutée du travail architecturale aux parties prenantes. À cet effet, ArchiMate définit le point de vue d’introduction :

Le point de vue d’introduction utilise une notation simplifiée qui constitue un sous-ensemble du langage ArchiMate complet. Il est généralement utilisé au début d’une trajectoire de conception, lorsque tout n’a pas encore besoin d’être détaillé, ou pour expliquer l’essence d’un modèle architecturale à des non-architectes qui ont besoin d’une notation plus simple et plus intuitive. Une autre utilisation de ce point de vue basique et moins formel est de tenter d’éviter l’impression que la conception architecturale est déjà figée — une impression qui est facilement créée lors de l’utilisation de visualisations plus formelles, hautement structurées ou détaillées.

L’équivalent TOGAF de ce point de vue est le diagramme de concept de solution.

L’exemple ci-dessous met en évidence les changements les plus importants nécessaires dans la situation actuelle de changement :

• Dans le bureau avant, le système CRM de gestion des frais juridiques séparé disparaîtra.
• Dans le bureau arrière, les applications back-office séparées seront remplacées par une seule suite back-office. Trois serveurs back-office communs séparés seront remplacés par un cluster de serveurs partagés et un cluster de serveurs de secours.

Figure 20 : Vue d’introduction

Phase B : Architecture commerciale cible et analyse des écarts

Dans cette situation, l’architecture commerciale reste inchangée. Toutefois, dans l’architecture commerciale, nous montrons également comment l’architecture cible réalise les exigences commerciales clés. À cet effet, TOGAF spécifie un diagramme de trace commerciale. En ArchiMate, cela peut être exprimé à l’aide du point de vue de réalisation des exigences, défini comme suit :

Le point de vue de réalisation des exigences permet au concepteur de modéliser la réalisation des exigences par des éléments clés tels que les acteurs commerciaux, les services commerciaux, les processus commerciaux, les services d’application, les composants d’application, etc. En général, les exigences proviennent du point de vue de raffinement des objectifs.

L’exemple ci-dessous montre comment les exigences commerciales établies dans la phase de vision architecturale sont réalisées par des éléments de l’architecture.

Figure 21 : Vue de réalisation des exigences

Phase C : Architecture des applications cible et analyse des écarts

Le diagramme de communication des applications ci-dessous montre la situation cible proposée du paysage des applications.

Figure 22 : Architecture des applications cible : Vue de coopération des applications

Les résultats globaux de l’analyse des écarts de l’architecture des applications sont indiqués ci-dessous. Plusieurs composants d’application présents dans l’architecture de référence n’existent plus dans l’architecture cible : les applications back-office séparées et le système CRM de gestion des frais juridiques pour l’assurance. La fonctionnalité CRM pour les clients d’assurance des frais juridiques est prise en charge par le système CRM commun ; par conséquent, cela ne nécessite pas de nouveau composant (bien que les systèmes CRM communs existants puissent nécessiter un ajustement ou une reconfiguration, cela n’est pas indiqué dans l’analyse des écarts). En outre, une nouvelle suite d’applications back-office entièrement nouvelle est introduite.

Figure 23 : Architecture des applications : Analyse des écarts

Phase D : Architecture technologique cible et analyse des écarts

La vue Infrastructure ci-dessous montre la situation cible proposée dans le domaine de l’infrastructure technologique.

Figure 24 : Architecture technologique cible : vue Infrastructure

La Figure 25 montre les résultats de l’analyse des écarts globaux de l’architecture technologique. Les serveurs communs séparés seront supprimés. Le cluster de serveurs original de Home & Away deviendra le cluster central de services back-office ArchiSurance, et un cluster de serveurs de sauvegarde supplémentaire sera placé au SSC siège de PRO-FIT. Un serveur de gestion de documents de sauvegarde est également présent dans le back-office de Home & Away. La nouvelle suite back-office et le système de gestion de documents seront répliqués sur les serveurs principaux et de sauvegarde respectifs.

Figure 25 : Architecture technologique : analyse des écarts

Mise en œuvre et planification de la migration

TOGAF 9 a introduit les architectures de transition pour les phases E et F, représentant des états intermédiaires possibles (« plateaux ») entre l’architecture de base et l’architecture cible.

Dans ArchiMate, les architectures de base, cible et de transition, ainsi que les relations entre elles, sont représentées à l’aide du point de vue de migration :

Le point de vue de migration contient des modèles et des concepts pouvant être utilisés pour spécifier la transition d’une architecture existante vers une architecture souhaitée.

La Figure 26 montre un exemple pour la situation actuelle. Le service informatique d’ArchiSurance ne dispose pas de ressources suffisantes pour exécuter l’intégration des systèmes back-office et l’intégration du système CRM en parallèle. Par conséquent, une architecture de transition remplace les deux systèmes CRM par un seul, mais dispose de systèmes back-office séparés. Une autre dispose d’une suite back-office mais de deux applications CRM.

Figure 26 : Vue de migration

Les architectures de transition soutiennent la planification des projets de mise en œuvre tels que l’intégration du CRM et l’intégration des applications back-office. La séquence de ces projets dépend de l’architecture de transition choisie. Cela peut être illustré dans le diagramme de contexte du projet TOGAF (Figure 27) :

Le diagramme de contexte du projet montre le périmètre des paquets de travail à réaliser dans le cadre d’une feuille de route de transformation plus large. Le diagramme de relations de contexte du projet relie les paquets de travail aux organisations, fonctions, services, processus, applications, données et technologies qui seront ajoutés, supprimés ou impactés par le projet.

Figure 27 : Diagramme de contexte du projet TOGAF représenté en ArchiMate

Scénario 2 : Gestion du portefeuille en ligne

Dans ce scénario, l’état cible du scénario 1 est pris comme nouvelle base, et les clients peuvent accéder directement à leur portefeuille d’assurance via le web. En permettant aux clients de :

• Acheter, renouveler ou modifier en toute sécurité leurs assurances habitation, voyage, automobile ou frais juridiques en ligne selon les règles utilisées par ArchiSurance lors de ses activités commerciales
• Obtenir de l’aide pour les transactions en ligne via :
  • Rechercher des réponses dans la base de connaissances
  • Lancer une session de chat avec un représentant du service client (CSR)
  • Rédiger et soumettre un courrier électronique via un formulaire web, répondu par un CSR
  • Demander un appel téléphonique d’un CSR via un formulaire web
• Obtenir des informations et des offres spéciales auprès des partenaires d’ArchiSurance pour répondre à leurs besoins, tels que les services bancaires et de planification financière, les investissements, les cartes de crédit et d’autres types d’assurance

Aucun modèle n’est actuellement disponible pour ce scénario. The Open Group encourage ses membres à contribuer aux futures versions de cette étude de cas. Les contributeurs peuvent enrichir ou ajouter des détails aux deux scénarios présentés ici ou créer de nouveaux scénarios. Toutefois, pour faciliter un ensemble cohérent de travaux, l’architecture de base des nouveaux scénarios de changement devrait être celle de la base ou de la cible des scénarios de changement présentés ici.

Références

1. TOGAF® Version 9.1, The Open Group, publié par The Open Group, 2011.
2. Spécification ArchiMate® 2.0, The Open Group, janvier 2012.
3. Doest, H., Iacob, M.-E., Lankhorst, M.M. (dir.), et van Leeuwen, D. : Fonctionnalités et exemples des points de vue, Livrable ArchiMate D3.4.1a v2, TI/RS/2003/091, Telematica Instituut, Enschede, Pays-Bas, 2004.
4. van den Berg, H., Moelaert, F. : Bench d’essai ouvert PRO-FIT Autoschade, Livrable Bench d’essai WP3/N004/V001, TRC, Enschede, Pays-Bas, 1997.
5. Qu’est-ce qu’ArchiMate ?
6. Guide complet sur les points de vue ArchiMate
7. Mise à jour ArchiMate 3
8. Nouveautés d’ArchiMate 3
9. Utilisation de l’outil ArchiMate avec le cadre TOGAF ADM
10. Comment utiliser le flux de valeur dans ArchiMate 3.1 ?
11. Nouveautés d’ArchiMate 3.1