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 ».

3 Language Structure

This chapter describes the structure of the ArchiMate Enterprise Architecture modeling language. The detailed definition and examples of its standard set of elements and relationships follow in Chapter 4 to Chapter 1

3.1 Language Design Considerations

A key challenge in the development of a general metamodel for Enterprise Architecture is to strike a balance between the specificity of languages for individual architecture domains and a very general set of architecture concepts, which reflects a view of systems as a mere set of inter-related entities.

The design of the ArchiMate language started from a set of relatively generic concepts. These have been specialized towards application at different architectural layers, as explained in the following sections. The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most Enterprise Architecture modeling tasks. Many other languages try to accommodate the needs of all possible users. In the interest of simplicity of learning and use, the ArchiMate language has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

This standard does not describe the detailed rationale behind the design of the ArchiMate language. The interested reader is referred to [1], [2], and [3], which provide a detailed description of the language construction and design considerations.

3.2 Top-Level Language Structure

Figure 1 outlines the top-level hierarchical structure of the language:

• A model is a collection of concepts – a concept is either an element or a relationship
• An element is either a behavior element, a structure element, a motivation element, or a composite element

Note that these are abstract concepts; they are not intended to be used directly in models. To signify this, they are depicted in white with labels in italics. See Chapter 4 for an explanation of the notation used in Figure 1.

Figure 1: Top-Level Hierarchy of ArchiMate Concepts

3.3 Layering of the ArchiMate Language

The ArchiMate core language defines a structure of generic elements and their relationships, which can be specialized in different layers. Three layers are defined within the ArchiMate core language as follows:

1. The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.
2. The Application Layer depicts application services that support the business, and the applications that realize them.
3. The Technology Layer comprises both information and operational technology. You can model, for example, processing, storage, and communication technology in support of the application world and Business Layers, and model operational or physical technology with facilities, physical equipment, materials, and distribution networks.

The general structure of models within the different layers is similar. The same types of elements and relationships are used, although their exact nature and granularity differ. In the next chapter, the structure of the generic metamodel is presented. In Chapter 8, Chapter 9, and Chapter 10 these elements are specialized to obtain elements specific to a particular layer.

In alignment with service-orientation, the most important relationship between layers is formed by “serving”[1] relationships, which show how the elements in one layer are served by the services of other layers. (Note, however, that services need not only serve elements in another layer, but also can serve elements in the same layer.) A second type of link is formed by realization relationships: elements in lower layers may realize comparable elements in higher layers; e.g., a

“data object” (Application Layer) may realize a “business object” (Business Layer); or an

“artifact” (Technology Layer) may realize either a “data object” or an “application component” (Application Layer).

3.4 The ArchiMate Core Framework

The ArchiMate Core Framework is a framework of nine cells used to classify elements of the ArchiMate core language. It is made up of three aspects and three layers, as illustrated in Figure 2. This is known as the ArchiMate Core Framework.

It is important to understand that the classification of elements based on aspects and layers is only a global one. Real-life architecture elements need not strictly be confined to one aspect or layer because elements that link the different aspects and layers, play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, business roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements, and it may depend on the context whether a certain piece of software is considered to be part of the Application Layer or the Technology Layer.

Figure 2: ArchiMate Core Framework

The structure of the framework allows for modeling of the enterprise from different viewpoints, where the position within the cells highlights the concerns of the stakeholder. A stakeholder typically can have concerns that cover multiple cells.

The dimensions of the framework are as follows:

• Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology (as described in Section 3.3)
• Aspects:

— The Active Structure Aspect, which represents the structural elements (the business actors, application components, and devices that display actual behavior; i.e., the

“subjects” of activity)

— The Behavior Aspect, which represents the behavior (processes, functions, events, and services) performed by the actors; structural elements are assigned to behavioral elements, to show who or what displays the behavior

— The Passive Structure Aspect, which represents the objects on which behavior is performed; these are usually information objects in the Business Layer and data objects in the Application Layer, but they may also be used to represent physical objects

These three aspects were inspired by natural language where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure). By using the same constructs that people are used to in their own languages, the ArchiMate language is easier to learn and read.

Since ArchiMate notation is a graphical language where elements are organized spatially, this order is of no consequence in modeling.

A composite element, as shown in Figure 1, is an element that does not necessarily fit in a single aspect (column) of the framework but may combine two or more aspects.

Note that the ArchiMate language does not require the modeler to use any particular layout such as the structure of this framework; it is merely a categorization of the language elements.

3.5 The ArchiMate Full Framework

The ArchiMate Full Framework, as described in this version of the standard, adds a number of layers and an aspect to the Core Framework_._ The physical elements are included in the Technology Layer for modeling physical facilities and equipment, distribution networks, and materials. As such, these are also core elements. The strategy elements are introduced to model strategic direction and choices. They are described in Chapter 7. The motivation aspect is introduced at a generic level in the next chapter and described in detail in Chapter 6. The implementation and migration elements are described in Chapter 12. The resulting ArchiMate Full Framework is shown in Figure 3.

Figure 3: ArchiMate Full Framework

The ArchiMate language does not define a specific layer for information; however, elements from the passive structure aspect such as business objects, data objects, and artifacts are used to represent information entities. Information modeling is supported across the different ArchiMate layers.

3.6 Abstraction in the ArchiMate Language

The structure of the ArchiMate language accommodates several familiar forms of abstraction and refinement. First of all, the distinction between an external (black-box, abstracting from the contents of the box) and internal (white-box) view is common in systems design. The external view depicts what the system has to do for its environment, while the internal view depicts how it does this.

Second, the distinction between behavior and active structure is commonly used to separate what the system must do and how the system does it from the system constituents (people, applications, and infrastructure) that do it. In modeling new systems, it is often useful to start with the behaviors that the system must perform, while in modeling existing systems, it is often useful to start with the people, applications, and infrastructure that comprise the system, and then analyze in detail the behaviors performed by these active structures.

A third distinction is between conceptual, logical, and physical abstraction levels. This has its roots in data modeling: conceptual elements represent the information the business finds relevant; logical elements provide logical structure to this information for manipulation by information systems; physical elements describe the storage of this information; for example, in the form of files or database tables. In the ArchiMate language, this corresponds with business objects, data objects, and artifacts, along with the realization relationships between them.

The distinction between logical and physical elements has also been carried over to the description of applications. The TOGAF Enterprise Metamodel [4] includes a set of entities that describe business, data, application, and technology components and services to describe architecture concepts. Logical components are implementation or product-independent encapsulations of data or functionality, whereas physical components are tangible software components, devices, etc. This distinction is captured in the TOGAF framework in the form of Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs). This distinction is again useful in progressing Enterprise Architectures from high-level, abstract descriptions to tangible, implementation-level designs. Note that building blocks may contain multiple elements, which are typically modeled using the grouping concept in the ArchiMate language.

The ArchiMate language has three ways of modeling such abstractions. First, as described in [6], behavior elements such as application and technology functions can be used to model logical components, since they represent implementation-independent encapsulations of functionality. The corresponding physical components can then be modeled using active structure elements such as application components and nodes, assigned to the behavior elements. Second, the ArchiMate language supports the concept of realization. This can best be described by working with the Technology Layer upwards. The Technology Layer defines the physical artifacts and software that realize an application component. It also provides a mapping to other physical concepts such as devices, networks, etc. needed for the realization of an information system. The realization relationship is also used to model more abstract kinds of realization, such as that between a (more specific) requirement and a (more generic) principle, where fulfillment of the requirement implies adherence to the principle. Realization is also allowed between application components and between nodes. This way you can model a physical application or technology component realizing a logical application or technology component, respectively. Third, logical and physical application components can be defined as metamodel-level specializations of the application component element, as described in Chapter 14 (see also the examples in Section 14.2.2). The same holds for the logical and physical technology components of the TOGAF Content Metamodel, which can be defined as specializations of the node element (see Section 14.2.3).

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML® class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

3.7 Concepts and their Notation

The ArchiMate language separates the language concepts (i.e., the constituents of the metamodel) from their notation. Different stakeholder groups may require different notations in order to understand an architecture model or view. In this respect, the ArchiMate language differs from languages such as UML or BPMN™, which have only one standardized notation. The viewpoint mechanism explained in Chapter 13 provides the means for defining such stakeholder-oriented visualizations.

Although the notation of the ArchiMate concepts can (and should) be stakeholder-specific, the standard provides one common graphical notation which can be used by architects and others who develop ArchiMate models. This notation is targeted towards an audience used to existing technical modeling techniques such as Entity Relationship Diagrams (ERDs), UML, or BPMN, and therefore resembles them. In the remainder of this document, unless otherwise noted, the symbols used to depict the language concepts represent the ArchiMate standard notation. This standard notation for most elements consists of a box with an icon in the upper-right corner. In several cases, this icon by itself may also be used as an alternative notation. This standard iconography should be preferred whenever possible so that anyone knowing the ArchiMate language can read the diagrams produced in the language.

3.8 Use of Nesting

Nesting elements inside other elements can be used as an alternative graphical notation to express some relationships. This is explained in more detail in Chapter 5 and in the definition of each of these relationships.

3.9 Use of Colors and Notational Cues

In the metamodel pictures within this standard, shades of grey are used to distinguish elements belonging to the different aspects of the ArchiMate framework, as follows:

• White for abstract (i.e., non-instantiable) concepts
• Light grey for passive structures
• Medium grey for behavior
• Dark grey for active structures

In ArchiMate models, there are no formal semantics assigned to colors and the use of color is left to the modeler. However, they can be used freely to stress certain aspects in models. For instance, in many of the example models presented in this standard, colors are used to distinguish between the layers of the ArchiMate Core Framework, as follows:

• Yellow for the Business Layer
• Blue for the Application Layer
• Green for the Technology Layer

They can also be used for visual emphasis. A recommended text providing guidelines is Chapter 6 of [1]. In addition to the colors, other notational cues can be used to distinguish between the layers of the framework. A letter M, S, B, A, T, P, or I in the top-left corner of an element can be used to denote a Motivation, Strategy, Business, Application, Technology, Physical, or Implementation & Migration element, respectively. An example of this notation is depicted in Example 34.

The standard notation also uses a convention with the shape of the corners of its symbols for different element types, as follows:

• Square corners are used to denote structure elements
• Round corners are used to denote behavior elements
• Diagonal corners are used to denote motivation elements

[1] Note that this was called “used by” in previous versions of the standard. For the sake of clarity, this name has been changed to “serving”.