3 Structure du langage

Ce chapitre décrit la structure du langage de modélisation ArchiMate pour l’architecture d’entreprise. La définition détaillée et des exemples de son ensemble standard d’éléments et de relations suivent au chapitre 4 au chapitre 1

3.1 Considérations sur la conception du langage

Un défi majeur dans le développement d’un méta-modèle général pour l’architecture d’entreprise consiste à trouver un équilibre entre la spécificité des langages pour les domaines d’architecture individuels et un ensemble très général de concepts d’architecture, qui reflète une vision des systèmes comme un simple ensemble d’entités interconnectées.

La conception du langage ArchiMate a commencé par un ensemble de concepts relativement génériques. Ces derniers ont été spécialisés pour être appliqués à différentes couches architecturales, comme expliqué dans les sections suivantes. La restriction de conception la plus importante du langage est qu’il a été explicitement conçu pour être aussi petit que possible, tout en restant utilisable pour la majorité des tâches de modélisation de l’architecture d’entreprise. Beaucoup d’autres langages cherchent à répondre aux besoins de tous les utilisateurs possibles. Dans l’intérêt de la simplicité d’apprentissage et d’utilisation, le langage ArchiMate a été limité aux concepts suffisants pour modéliser les 80 % environ des cas pratiques.

Cette norme ne décrit pas la justification détaillée derrière la conception du langage ArchiMate. Le lecteur intéressé est invité à consulter [1], [2] et [3], qui fournissent une description détaillée de la construction du langage et des considérations de conception.

3.2 Structure de niveau supérieur du langage

La figure 1 présente la structure hiérarchique de niveau supérieur du langage :

• Un modèle est une collection deconcepts– un concept est soit unélémentsoit unerelation
• Un élément est soit un élément de comportement, un élément de structure, un élément de motivation, soit un élément composite

Notez que ce sont desconcepts abstraitsconcepts ; ils ne sont pas destinés à être utilisés directement dans les modèles. Pour indiquer cela, ils sont représentés en blanc avec des étiquettes en italique. Voir le chapitre 4 pour une explication de la notation utilisée dans la figure 1.

Figure 1 : Hiérarchie de niveau supérieur des concepts ArchiMate

3.3 Stratification du langage ArchiMate

Le langage central ArchiMate définit une structure d’éléments génériques et de leurs relations, qui peuvent être spécialisés dans différentes couches. Trois couches sont définies dans le langage central ArchiMate comme suit :

1. Lacouche Métierreprésente les services métiers offerts aux clients, qui sont réalisés au sein de l’organisation par des processus métiers effectués par des acteurs métiers.
2. Lacouche Applicationreprésente les services d’application qui soutiennent le métier, ainsi que les applications qui les réalisent.
3. Lacouche Technologiecomprend à la fois la technologie de l’information et la technologie opérationnelle. Vous pouvez modéliser, par exemple, la technologie de traitement, de stockage et de communication en soutien au monde des applications et aux couches métier, et modéliser la technologie opérationnelle ou physique à l’aide d’installations, d’équipements physiques, de matériaux et de réseaux de distribution.

La structure générale des modèles au sein des différentes couches est similaire. Les mêmes types d’éléments et de relations sont utilisés, bien que leur nature exacte et leur granularité diffèrent. Dans le chapitre suivant, la structure du méta-modèle générique est présentée. Dans les chapitres 8, 9 et 10, ces éléments sont spécialisés afin d’obtenir des éléments spécifiques à une couche particulière.

En cohérence avec l’orientation vers les services, la relation la plus importante entre les couches est celle de « service »[1]relations, qui montrent comment les éléments d’une couche sont servis par les services d’autres couches. (Notez toutefois que les services ne servent pas uniquement des éléments d’une autre couche, mais peuvent également servir des éléments de la même couche.) Un deuxième type de lien est formé par les relations de réalisation : les éléments des couches inférieures peuvent réaliser des éléments comparables des couches supérieures ; par exemple, un

« objet de données » (couche d’application) peut réaliser un « objet métier » (couche métier) ; ou un

« artefact » (couche technologique) peut réaliser soit un « objet de données », soit un « composant d’application » (couche d’application).

3.4 Le cadre central ArchiMate

Le cadre central ArchiMate est un cadre composé de neuf cellules utilisé pour classer les éléments du langage central ArchiMate. Il est constitué de trois aspects et de trois couches, comme illustré à la figure 2. Ce cadre est connu sous le nom de cadre central ArchiMate.

Il est important de comprendre que la classification des éléments basée sur les aspects et les couches n’est qu’une classification globale. Les éléments d’architecture du monde réel n’ont pas nécessairement à être strictement confinés à un seul aspect ou couche, car les éléments qui relient les différents aspects et couches jouent un rôle central dans une description architecturale cohérente. Par exemple, en avançant un peu par rapport aux discussions conceptuelles ultérieures, les rôles métiers servent d’éléments intermédiaires entre les éléments « purement comportementaux » et les éléments « purement structurels », et cela peut dépendre du contexte pour déterminer si un certain logiciel est considéré comme faisant partie de la couche d’application ou de la couche technologique.

Figure 2 : Cadre central ArchiMate

La structure du cadre permet de modéliser l’entreprise à partir de différents points de vue, où la position à l’intérieur des cellules met en évidence les préoccupations du partie prenante. Un partie prenante peut généralement avoir des préoccupations couvrant plusieurs cellules.

Les dimensions du cadre sont les suivantes :

• Couches – les trois niveaux auxquels une entreprise peut être modélisée dans ArchiMate – Métier, Application et Technologie (comme décrit dans la section 3.3)
• Aspects :

— LeAspect de la structure active, qui représente les éléments structurels (les acteurs métiers, les composants d’application et les dispositifs qui affichent un comportement réel ; c’est-à-dire les

« sujets » de l’activité)

— LeAspect du comportement, qui représente le comportement (processus, fonctions, événements et services) effectués par les acteurs ; les éléments structurels sont attribués aux éléments comportementaux, afin de montrer qui ou quoi affiche le comportement

— LeAspect de la structure passive, qui représente les objets sur lesquels le comportement est effectué ; il s’agit généralement d’objets d’information dans la couche métier et d’objets de données dans la couche d’application, mais ils peuvent également être utilisés pour représenter des objets physiques

Ces trois aspects ont été inspirés par le langage naturel, où une phrase possède un sujet (structure active), un verbe (comportement) et un objet (structure passive). En utilisant les mêmes constructions auxquelles les personnes sont habituées dans leurs propres langues, le langage ArchiMate est plus facile à apprendre et à lire.

Étant donné que la notation ArchiMate est unlangage graphiqueoù les éléments sont organisés spatialement, cet ordre n’a aucune importance dans la modélisation.

Un élément composite, comme illustré à la figure 1, est un élément qui n’est pas nécessairement confiné à un seul aspect (colonne) du cadre, mais peut combiner deux ou plusieurs aspects.

Notez que le langage ArchiMate ne demande pas au concepteur d’utiliser un agencement particulier tel que la structure de ce cadre ; il s’agit simplement d’une catégorisation des éléments du langage.

3.5 Le cadre complet ArchiMate

Le cadre complet ArchiMate, tel qu’il est décrit dans cette version de la norme, ajoute plusieurs couches et un aspect au cadre de base. Les éléments physiques sont inclus dans la couche Technologie pour modéliser les installations physiques, les équipements, les réseaux de distribution et les matériaux. En tant que tels, ils constituent également des éléments fondamentaux. Les éléments stratégiques sont introduits pour modéliser la direction stratégique et les choix. Ils sont décrits au chapitre 7. L’aspect motivation est introduit à un niveau générique au chapitre suivant et décrit en détail au chapitre 6. Les éléments de mise en œuvre et de migration sont décrits au chapitre 12. Le cadre complet ArchiMate résultant est illustré à la figure 3.

Figure 3 : Cadre complet ArchiMate

Le langage ArchiMate ne définit pas de couche spécifique pour l’information ; toutefois, des éléments de l’aspect structure passive, tels que les objets métiers, les objets de données et les artefacts, sont utilisés pour représenter des entités d’information. La modélisation de l’information est soutenue à travers les différentes couches ArchiMate.

3.6 Abstraction dans le langage ArchiMate

La structure du langage ArchiMate permet plusieurs formes familières d’abstraction et de raffinement. Tout d’abord, la distinction entre une vue externe (boîte noire, abstraction du contenu de la boîte) et une vue interne (boîte blanche) est courante dans la conception des systèmes. La vue externe illustre ce que le système doit accomplir pour son environnement, tandis que la vue interne montre comment il le fait.

En second lieu, la distinction entre comportement et structure active est couramment utilisée pour séparer ce que le système doit faire et comment il le fait, des constituants du système (personnes, applications et infrastructures) qui le réalisent. Dans la modélisation de nouveaux systèmes, il est souvent utile de commencer par les comportements que le système doit accomplir, tandis que dans la modélisation de systèmes existants, il est souvent utile de commencer par les personnes, applications et infrastructures qui composent le système, puis d’analyser en détail les comportements réalisés par ces structures actives.

Une troisième distinction existe entre les niveaux d’abstraction conceptuelle, logique et physique. Cela trouve ses racines dans la modélisation des données : les éléments conceptuels représentent l’information que l’entreprise juge pertinente ; les éléments logiques fournissent une structure logique à cette information pour qu’elle puisse être manipulée par les systèmes d’information ; les éléments physiques décrivent le stockage de cette information, par exemple sous forme de fichiers ou de tables de base de données. Dans le langage ArchiMate, cela correspond aux objets métiers, objets de données et artefacts, ainsi que aux relations de réalisation entre eux.

La distinction entre éléments logiques et physiques a également été appliquée à la description des applications. Le métamodèle d’entreprise TOGAF [4] inclut un ensemble d’entités qui décrivent les composants et services métiers, de données, d’applications et technologiques pour décrire les concepts d’architecture. Les composants logiques sont des encapsulations indépendantes de l’implémentation ou du produit, qu’il s’agisse de données ou de fonctionnalités, tandis que les composants physiques sont des composants logiciels tangibles, des dispositifs, etc. Cette distinction est intégrée dans le cadre TOGAF sous la forme de Blocs de construction d’architecture (ABB) et de Blocs de construction de solution (SBB). Cette distinction est à nouveau utile pour passer des descriptions abstraites de haut niveau à des conceptions concrètes et de niveau d’implémentation dans les architectures d’entreprise. Notez que les blocs de construction peuvent contenir plusieurs éléments, qui sont généralement modélisés à l’aide du concept de regroupement dans le langage ArchiMate.

Le langage ArchiMate dispose de trois façons de modéliser ces abstractions. Premièrement, comme indiqué dans [6], les éléments de comportement tels que les fonctions d’application et de technologie peuvent être utilisés pour modéliser des composants logiques, car ils représentent des encapsulations indépendantes de l’implémentation de fonctionnalités. Les composants physiques correspondants peuvent ensuite être modélisés à l’aide d’éléments de structure active tels que les composants d’application et les nœuds, affectés aux éléments de comportement. Deuxièmement, le langage ArchiMate supporte le concept de réalisation. Cela peut être le mieux décrit en travaillant à partir de la couche Technologie vers le haut. La couche Technologie définit les artefacts physiques et le logiciel qui réalisent un composant d’application. Elle fournit également une correspondance avec d’autres concepts physiques tels que les dispositifs, les réseaux, etc., nécessaires à la réalisation d’un système d’information. La relation de réalisation est également utilisée pour modéliser des formes plus abstraites de réalisation, telles que celle entre une exigence (plus spécifique) et un principe (plus général), où la satisfaction de l’exigence implique le respect du principe. La réalisation est également autorisée entre composants d’application et entre nœuds. Ainsi, on peut modéliser un composant d’application ou technologique physique réalisant un composant d’application ou technologique logique, respectivement. Troisièmement, les composants d’application logiques et physiques peuvent être définis comme des spécialisations au niveau du métamodèle de l’élément composant d’application, comme décrit au chapitre 14 (voir également les exemples dans la section 14.2.2). Le même principe s’applique aux composants technologiques logiques et physiques du métamodèle de contenu TOGAF, qui peuvent être définis comme des spécialisations de l’élément nœud (voir la section 14.2.3).

Le langage ArchiMate ne supporte intentionnellement aucune distinction entre types et instances. Au niveau d’abstraction de l’architecture d’entreprise, il est plus courant de modéliser des types et/ou des exemplaires plutôt que des instances. De même, un processus métier dans le langage ArchiMate ne décrit pas une instance individuelle (c’est-à-dire une exécution de ce processus). Dans la plupart des cas, un objet métier est donc utilisé pour modéliser un type d’objet (cf. une classe UML®), dont plusieurs instances peuvent exister au sein de l’organisation. Par exemple, chaque exécution d’un processus de demande d’assurance peut donner lieu à une instance spécifique de l’objet métier assurance, mais cela n’est pas modélisé dans l’architecture d’entreprise.

3.7 Concepts et leur notation

Le langage ArchiMate sépare les concepts du langage (c’est-à-dire les constituants du métamodèle) de leur notation. Des groupes de parties prenantes différents peuvent nécessiter des notations différentes afin de comprendre un modèle ou une vue d’architecture. À cet égard, le langage ArchiMate diffère des langages tels que UML ou BPMN™, qui disposent d’une seule notation standardisée. Le mécanisme de point de vue expliqué au chapitre 13 fournit les moyens de définir ces visualisations orientées vers les parties prenantes.

Bien que la notation des concepts ArchiMate puisse (et devrait) être spécifique aux parties prenantes, la norme fournit une notation graphique commune qui peut être utilisée par les architectes et autres personnes développant des modèles ArchiMate. Cette notation s’adresse à un public familier avec les techniques de modélisation technique existantes telles que les diagrammes Entité-Relation (ERD), UML ou BPMN, et lui ressemble donc. Dans le reste du document, sauf indication contraire, les symboles utilisés pour représenter les concepts du langage représentent la notation standard ArchiMate. Cette notation standard pour la plupart des éléments consiste en une boîte avec une icône dans le coin supérieur droit. Dans plusieurs cas, cette icône seule peut également être utilisée comme notation alternative. Cette iconographie standard devrait être privilégiée chaque fois que possible afin que quiconque connaissant le langage ArchiMate puisse lire les diagrammes produits dans ce langage.

3.8 Utilisation du regroupement

Le regroupement d’éléments à l’intérieur d’autres éléments peut être utilisé comme notation graphique alternative pour exprimer certaines relations. Cela est expliqué plus en détail au chapitre 5 et dans la définition de chacune de ces relations.

3.9 Utilisation des couleurs et des indices notationnels

Dans les illustrations du métamodèle de cette norme, des nuances de gris sont utilisées pour distinguer les éléments appartenant aux différents aspects du cadre ArchiMate, comme suit :

• Blanc pour les concepts abstraits (c’est-à-dire non instanciables)
• Gris clair pour les structures passives
• Gris moyen pour le comportement
• Gris foncé pour les structures actives

Dans les modèles ArchiMate, aucune sémantique formelle n’est attribuée aux couleurs, et l’utilisation des couleurs est laissée au choix du concepteur. Toutefois, elles peuvent être utilisées librement pour souligner certains aspects des modèles. Par exemple, dans de nombreux modèles d’exemple présentés dans cette norme, les couleurs sont utilisées pour distinguer les couches du cadre de base ArchiMate, comme suit :

• Jaune pour la couche Métier
• Bleu pour la couche Application
• Vert pour la couche Technologie

Ils peuvent également être utilisés pour un effet visuel. Un document recommandé fournissant des directives est le chapitre 6 de [1]. En plus des couleurs, d’autres indices notationnels peuvent être utilisés pour distinguer les couches du cadre. Une lettre M, S, B, A, T, P ou I dans le coin supérieur gauche d’un élément peut être utilisée pour indiquer respectivement un élément de motivation, de stratégie, de métier, d’application, de technologie, physique ou de mise en œuvre et migration. Un exemple de cette notation est illustré à l’exemple 34.

La notation standard utilise également une convention concernant la forme des coins de ses symboles pour différents types d’éléments, comme suit :

• Les coins carrés sont utilisés pour indiquer les éléments de structure
• Les coins arrondis sont utilisés pour indiquer les éléments de comportement
• Les coins diagonaux sont utilisés pour indiquer les éléments de motivation

[1]Notez que cela était appelé « utilisé par » dans les versions précédentes de la norme. Pour plus de clarté, ce nom a été changé en « servant ».