3 Estructura del lenguaje

Este capítulo describe la estructura del lenguaje de modelado de Arquitectura Empresarial ArchiMate. La definición detallada y los ejemplos de su conjunto estándar de elementos y relaciones se presentan en el Capítulo 4 al Capítulo 1

3.1 Consideraciones sobre el diseño del lenguaje

Un desafío clave en el desarrollo de un metamodelo general para la Arquitectura Empresarial es encontrar un equilibrio entre la especificidad de los lenguajes para dominios arquitectónicos individuales y un conjunto muy general de conceptos arquitectónicos, que refleja una visión de los sistemas como un simple conjunto de entidades interrelacionadas.

El diseño del lenguaje ArchiMate partió de un conjunto de conceptos relativamente genéricos. Estos han sido especializados para su aplicación en diferentes capas arquitectónicas, tal como se explica en las secciones siguientes. La restricción de diseño más importante del lenguaje es que ha sido explícitamente diseñado para ser lo más pequeño posible, pero aún así útil para la mayoría de las tareas de modelado de Arquitectura Empresarial. Muchos otros lenguajes intentan satisfacer las necesidades de todos los usuarios posibles. En interés de la simplicidad del aprendizaje y uso, el lenguaje ArchiMate se ha limitado a los conceptos que bastan para modelar el famoso 80 % de los casos prácticos.

Esta norma no describe la justificación detallada detrás del diseño del lenguaje ArchiMate. El lector interesado se remite a [1], [2] y [3], que ofrecen una descripción detallada de la construcción del lenguaje y las consideraciones de diseño.

3.2 Estructura de nivel superior del lenguaje

La Figura 1 muestra la estructura jerárquica de nivel superior del lenguaje:

• Un modelo es una colección deconceptos– un concepto es o bien unelementoo unrelación
• Un elemento es o bien un elemento de comportamiento, un elemento de estructura, un elemento de motivación o un elemento compuesto

Observe que estos sonconceptos abstractosconceptos; no están pensados para usarse directamente en modelos. Para indicar esto, se representan en blanco con etiquetas en cursiva. Véase el Capítulo 4 para una explicación de la notación utilizada en la Figura 1.

Figura 1: Jerarquía de nivel superior de los conceptos ArchiMate

3.3 Capas del lenguaje ArchiMate

El lenguaje principal ArchiMate define una estructura de elementos genéricos y sus relaciones, que pueden ser especializados en diferentes capas. Se definen tres capas dentro del lenguaje principal ArchiMate de la siguiente manera:

1. LaCapa de Negociosmuestra los servicios de negocio ofrecidos a los clientes, que se realizan en la organización mediante procesos de negocio realizados por actores de negocio.
2. LaCapa de Aplicacionesmuestra los servicios de aplicación que apoyan al negocio, y las aplicaciones que los realizan.
3. LaCapa de Tecnologíacomprende tanto la tecnología de información como la tecnología operativa. Por ejemplo, puede modelar tecnología de procesamiento, almacenamiento y comunicación para apoyar al mundo de las aplicaciones y las capas de negocio, y modelar tecnología operativa o física con instalaciones, equipos físicos, materiales y redes de distribución.

La estructura general de los modelos dentro de las diferentes capas es similar. Se utilizan los mismos tipos de elementos y relaciones, aunque su naturaleza y grado de detalle difieren. En el próximo capítulo se presenta la estructura del metamodelo genérico. En los capítulos 8, 9 y 10 se especializan estos elementos para obtener elementos específicos de una capa determinada.

En alineación con la orientación a servicios, la relación más importante entre capas se forma mediante la relación de “servicio”[1]relaciones, que muestran cómo los elementos de una capa son servidos por los servicios de otras capas. (Observe, sin embargo, que los servicios no solo deben servir elementos en otra capa, sino que también pueden servir elementos en la misma capa.) Un segundo tipo de enlace se forma mediante relaciones de realización: los elementos de capas inferiores pueden realizar elementos comparables de capas superiores; por ejemplo, un

objeto de datos (capa de aplicaciones) puede realizar un objeto de negocio (capa de negocio); o un

artefacto (capa de tecnología) puede realizar un objeto de datos o un componente de aplicación (capa de aplicaciones).

3.4 El marco central de ArchiMate

El marco central de ArchiMate es un marco de nueve celdas utilizado para clasificar los elementos del lenguaje central de ArchiMate. Está compuesto por tres aspectos y tres capas, como se ilustra en la Figura 2. Esto se conoce como el marco central de ArchiMate.

Es importante comprender que la clasificación de elementos basada en aspectos y capas es solo una clasificación general. Los elementos de arquitectura de la vida real no necesitan estar estrictamente confinados a un aspecto o capa, ya que los elementos que enlazan diferentes aspectos y capas desempeñan un papel central en una descripción arquitectónica coherente. Por ejemplo, adelantándose un poco respecto a los posteriores debates conceptuales, los roles de negocio actúan como elementos intermedios entre elementos “puramente conductuales” y elementos “puramente estructurales”, y puede depender del contexto si cierto software se considera parte de la capa de aplicaciones o de la capa de tecnología.

Figura 2: Marco central de ArchiMate

La estructura del marco permite modelar la empresa desde diferentes puntos de vista, donde la posición dentro de las celdas resalta las preocupaciones del interesado. Un interesado normalmente puede tener preocupaciones que abarcan múltiples celdas.

Las dimensiones del marco son las siguientes:

• Capas – los tres niveles en los que una empresa puede ser modelada en ArchiMate – Negocio, Aplicación y Tecnología (como se describe en la sección 3.3)
• Aspectos:

— ElAspecto de Estructura Activa, que representa los elementos estructurales (los actores de negocio, componentes de aplicación y dispositivos que muestran un comportamiento real; es decir, los

“sujetos” de la actividad)

— ElAspecto de Comportamiento, que representa el comportamiento (procesos, funciones, eventos y servicios) realizados por los actores; se asignan elementos estructurales a elementos conductuales, para mostrar quién o qué muestra el comportamiento

— ElAspecto de Estructura Pasiva, que representa los objetos sobre los que se realiza el comportamiento; normalmente son objetos de información en la capa de negocio y objetos de datos en la capa de aplicaciones, pero también pueden usarse para representar objetos físicos

Estos tres aspectos fueron inspirados por el lenguaje natural, donde una oración tiene un sujeto (estructura activa), un verbo (comportamiento) y un objeto (estructura pasiva). Al utilizar los mismos constructos con los que las personas están familiarizadas en sus propios idiomas, el lenguaje ArchiMate es más fácil de aprender y leer.

Dado que la notación ArchiMate es unlenguaje gráficoen el que los elementos se organizan espacialmente, este orden no tiene consecuencia en la modelización.

Un elemento compuesto, como se muestra en la Figura 1, es un elemento que no necesariamente encaja en un solo aspecto (columna) del marco, sino que puede combinar dos o más aspectos.

Tenga en cuenta que el lenguaje ArchiMate no exige al modelador utilizar ningún diseño particular, como la estructura de este marco; simplemente se trata de una categorización de los elementos del lenguaje.

3.5 El marco completo ArchiMate

El marco completo ArchiMate, tal como se describe en esta versión de la norma, añade varias capas y un aspecto al marco central. Los elementos físicos se incluyen en la Capa de Tecnología para modelar instalaciones físicas, equipos, redes de distribución y materiales. Por tanto, también son elementos centrales. Los elementos estratégicos se introducen para modelar direcciones y decisiones estratégicas. Se describen en el Capítulo 7. El aspecto de motivación se introduce a un nivel genérico en el siguiente capítulo y se describe en detalle en el Capítulo 6. Los elementos de implementación y migración se describen en el Capítulo 12. El marco completo ArchiMate resultante se muestra en la Figura 3.

Figura 3: Marca completo ArchiMate

El lenguaje ArchiMate no define una capa específica para la información; sin embargo, se utilizan elementos del aspecto de estructura pasiva, como objetos de negocio, objetos de datos y artefactos, para representar entidades de información. La modelización de información se apoya en todas las capas de ArchiMate.

3.6 Abstracción en el lenguaje ArchiMate

La estructura del lenguaje ArchiMate permite varias formas familiares de abstracción y refinamiento. En primer lugar, la distinción entre una vista externa (caja negra, abstrayendo del contenido de la caja) y una vista interna (caja blanca) es común en el diseño de sistemas. La vista externa representa lo que el sistema debe hacer para su entorno, mientras que la vista interna representa cómo lo hace.

En segundo lugar, la distinción entre comportamiento y estructura activa se utiliza comúnmente para separar lo que el sistema debe hacer y cómo lo hace, de los componentes del sistema (personas, aplicaciones e infraestructura) que lo realizan. Al modelar sistemas nuevos, a menudo resulta útil comenzar con los comportamientos que el sistema debe realizar, mientras que al modelar sistemas existentes, a menudo resulta útil comenzar con las personas, aplicaciones e infraestructura que componen el sistema, y luego analizar en detalle los comportamientos realizados por estas estructuras activas.

Una tercera distinción es entre los niveles de abstracción conceptual, lógico y físico. Tiene sus raíces en la modelización de datos: los elementos conceptuales representan la información que la empresa considera relevante; los elementos lógicos proporcionan una estructura lógica a esta información para su manipulación por sistemas de información; los elementos físicos describen el almacenamiento de esta información; por ejemplo, en forma de archivos o tablas de base de datos. En el lenguaje ArchiMate, esto corresponde a objetos de negocio, objetos de datos y artefactos, junto con las relaciones de realización entre ellos.

La distinción entre elementos lógicos y físicos también se ha extendido a la descripción de aplicaciones. El Metamodelo Empresarial TOGAF [4] incluye un conjunto de entidades que describen componentes y servicios de negocio, datos, aplicaciones y tecnología para describir conceptos de arquitectura. Los componentes lógicos son encapsulaciones independientes de implementación o producto de datos o funcionalidad, mientras que los componentes físicos son componentes de software tangibles, dispositivos, etc. Esta distinción se captura en el marco TOGAF en forma de Bloques de Arquitectura (ABBs) y Bloques de Solución (SBBs). Esta distinción resulta nuevamente útil para avanzar desde descripciones de arquitectura de alto nivel y abstractas hasta diseños tangibles y de nivel de implementación. Tenga en cuenta que los bloques pueden contener múltiples elementos, que normalmente se modelan utilizando el concepto de agrupación en el lenguaje ArchiMate.

El lenguaje ArchiMate tiene tres formas de modelar estas abstracciones. En primer lugar, como se describe en [6], los elementos de comportamiento, como funciones de aplicación y tecnología, pueden usarse para modelar componentes lógicos, ya que representan encapsulaciones independientes de implementación de funcionalidad. Los componentes físicos correspondientes pueden luego modelarse utilizando elementos de estructura activa, como componentes de aplicación y nodos, asignados a los elementos de comportamiento. En segundo lugar, el lenguaje ArchiMate apoya el concepto de realización. Esto se puede describir mejor trabajando desde la Capa de Tecnología hacia arriba. La Capa de Tecnología define los artefactos físicos y el software que realizan un componente de aplicación. También proporciona un mapeo a otros conceptos físicos, como dispositivos, redes, etc., necesarios para la realización de un sistema de información. La relación de realización también se utiliza para modelar tipos más abstractos de realización, como la que existe entre un requisito (más específico) y un principio (más genérico), donde el cumplimiento del requisito implica el cumplimiento del principio. La realización también está permitida entre componentes de aplicación y entre nodos. De esta manera, se puede modelar un componente físico de aplicación o tecnología que realiza un componente lógico de aplicación o tecnología, respectivamente. En tercer lugar, los componentes de aplicación lógicos y físicos pueden definirse como especializaciones a nivel de metamodelo del elemento componente de aplicación, tal como se describe en el Capítulo 14 (véase también los ejemplos en la Sección 14.2.2). Lo mismo se aplica a los componentes tecnológicos lógicos y físicos del Metamodelo de Contenido TOGAF, que pueden definirse como especializaciones del elemento nodo (véase la Sección 14.2.3).

El lenguaje ArchiMate no admite intencionalmente una diferencia entre tipos e instancias. A nivel de abstracción de Arquitectura Empresarial, es más común modelar tipos y/o ejemplares en lugar de instancias. Asimismo, un proceso de negocio en el lenguaje ArchiMate no describe una instancia individual (es decir, una ejecución de ese proceso). En la mayoría de los casos, se utiliza un objeto de negocio para modelar un tipo de objeto (cf. una clase UML®), de los cuales pueden existir varias instancias dentro de la organización. Por ejemplo, cada ejecución de un proceso de solicitud de seguros puede dar lugar a una instancia específica del objeto de negocio de póliza de seguros, pero eso no se modela en la Arquitectura Empresarial.

3.7 Conceptos y su notación

El lenguaje ArchiMate separa los conceptos del lenguaje (es decir, los constituyentes del metamodelo) de su notación. Grupos diferentes de interesados pueden requerir notaciones distintas para comprender un modelo o vista de arquitectura. En este aspecto, el lenguaje ArchiMate se diferencia de lenguajes como UML o BPMN™, que tienen una única notación estandarizada. El mecanismo de punto de vista explicado en el Capítulo 13 proporciona los medios para definir visualizaciones orientadas a los interesados.

Aunque la notación de los conceptos ArchiMate puede (y debería) ser específica del interesado, la norma proporciona una notación gráfica común que puede ser utilizada por arquitectos y otros que desarrollan modelos ArchiMate. Esta notación está dirigida a un público familiarizado con técnicas técnicas de modelado existentes, como Diagramas de Relación de Entidades (ERD), UML o BPMN, y por tanto se asemeja a ellas. En el resto de este documento, salvo que se indique lo contrario, los símbolos utilizados para representar los conceptos del lenguaje representan la notación estándar ArchiMate. Esta notación estándar para la mayoría de los elementos consiste en un cuadro con un icono en la esquina superior derecha. En varios casos, este icono por sí solo también puede usarse como una notación alternativa. Esta iconografía estándar debería preferirse siempre que sea posible, para que cualquier persona que conozca el lenguaje ArchiMate pueda leer los diagramas producidos en el lenguaje.

3.8 Uso de anidamiento

El anidamiento de elementos dentro de otros elementos puede usarse como una notación gráfica alternativa para expresar algunas relaciones. Esto se explica con más detalle en el Capítulo 5 y en la definición de cada una de estas relaciones.

3.9 Uso de colores y señales notacionales

En las imágenes del metamodelo dentro de esta norma, se utilizan tonos de gris para distinguir los elementos que pertenecen a los diferentes aspectos del marco ArchiMate, de la siguiente manera:

• Blanco para conceptos abstractos (es decir, no instanciables)
• Gris claro para estructuras pasivas
• Gris medio para comportamiento
• Gris oscuro para estructuras activas

En los modelos ArchiMate, no se asignan semánticas formales a los colores y el uso del color queda a criterio del modelador. Sin embargo, pueden usarse libremente para resaltar ciertos aspectos en los modelos. Por ejemplo, en muchos de los modelos de ejemplo presentados en esta norma, se utilizan colores para distinguir entre las capas del marco central ArchiMate, de la siguiente manera:

• Amarillo para la Capa de Negocio
• Azul para la Capa de Aplicación
• Verde para la Capa de Tecnología

También pueden usarse para énfasis visual. Un texto recomendado que proporciona directrices es el Capítulo 6 de [1]. Además de los colores, se pueden utilizar otras señales notacionales para distinguir entre las capas del marco. Una letra M, S, B, A, T, P o I en la esquina superior izquierda de un elemento puede usarse para indicar un elemento de Motivación, Estrategia, Negocio, Aplicación, Tecnología, Físico o Implementación y Migración, respectivamente. Un ejemplo de esta notación se muestra en el Ejemplo 34.

La notación estándar también utiliza una convención con la forma de las esquinas de sus símbolos para diferentes tipos de elementos, como sigue:

• Las esquinas cuadradas se utilizan para denotar elementos de estructura
• Las esquinas redondeadas se utilizan para denotar elementos de comportamiento
• Las esquinas diagonales se utilizan para denotar elementos de motivación

[1]Observe que esto se llamaba «usado por» en versiones anteriores de la norma. Por razones de claridad, este nombre ha sido cambiado a «servir».

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