3 Estrutura da Linguagem

Este capítulo descreve a estrutura da linguagem de modelagem de Arquitetura Empresarial ArchiMate. A definição detalhada e exemplos do conjunto padrão de elementos e relacionamentos seguem nos Capítulos 4 ao 1

3.1 Considerações sobre o Design da Linguagem

Um desafio fundamental no desenvolvimento de um metamodelo geral para Arquitetura Empresarial é encontrar um equilíbrio entre a especificidade das linguagens para domínios de arquitetura individuais e um conjunto muito geral de conceitos de arquitetura, que reflete uma visão de sistemas como um simples conjunto de entidades inter-relacionadas.

O design da linguagem ArchiMate começou a partir de um conjunto de conceitos relativamente genéricos. Esses foram especializados para aplicação em diferentes camadas arquitetônicas, conforme explicado nas seções seguintes. A restrição de design mais importante da linguagem é que foi explicitamente projetada para ser o mais pequena possível, mas ainda utilizável para a maioria das tarefas de modelagem de Arquitetura Empresarial. Muitas outras linguagens tentam atender às necessidades de todos os usuários possíveis. Em benefício da simplicidade de aprendizado e uso, a linguagem ArchiMate foi limitada aos conceitos suficientes para modelar os famosos 80% dos casos práticos.

Este padrão não descreve a justificativa detalhada por trás do design da linguagem ArchiMate. O leitor interessado é remetido aos [1], [2] e [3], que fornecem uma descrição detalhada da construção da linguagem e das considerações de design.

3.2 Estrutura de Nível Superior da Linguagem

A Figura 1 apresenta a estrutura hierárquica de nível superior da linguagem:

• Um modelo é uma coleção deconceitos– um conceito é ou umelementoou umrelacionamento
• Um elemento é ou um elemento de comportamento, um elemento de estrutura, um elemento de motivação ou um elemento composto

Observe que esses sãoabstratosconceitos; eles não são destinados a ser usados diretamente em modelos. Para indicar isso, são representados em branco com rótulos em itálico. Consulte o Capítulo 4 para uma explicação da notação usada na Figura 1.

Figura 1: Hierarquia de Nível Superior dos Conceitos ArchiMate

3.3 Camadas da Linguagem ArchiMate

A linguagem principal ArchiMate define uma estrutura de elementos genéricos e seus relacionamentos, que podem ser especializados em diferentes camadas. Três camadas são definidas na linguagem principal ArchiMate da seguinte forma:

1. ACamada de Negóciosdescreve os serviços de negócios oferecidos aos clientes, que são realizados na organização por processos de negócios realizados por atores de negócios.
2. ACamada de Aplicaçãodescreve os serviços de aplicação que sustentam os negócios, e as aplicações que os realizam.
3. ACamada de Tecnologiacompreende tanto tecnologia de informação quanto tecnologia operacional. Você pode modelar, por exemplo, tecnologia de processamento, armazenamento e comunicação em apoio ao mundo de aplicativos e às camadas de negócios, e modelar tecnologia operacional ou física com instalações, equipamentos físicos, materiais e redes de distribuição.

A estrutura geral dos modelos dentro das diferentes camadas é semelhante. São usados os mesmos tipos de elementos e relações, embora sua natureza e granularidade exatas diferem. No próximo capítulo, é apresentada a estrutura do metamodelo genérico. Nos Capítulos 8, 9 e 10, esses elementos são especializados para obter elementos específicos de uma camada particular.

Alinhado com a orientação por serviços, a relação mais importante entre as camadas é formada por “serviço”[1]relações, que mostram como os elementos em uma camada são atendidos pelos serviços de outras camadas. (Observe, no entanto, que os serviços não precisam apenas atender elementos em outra camada, mas também podem atender elementos na mesma camada.) Um segundo tipo de ligação é formado por relações de realização: elementos em camadas inferiores podem realizar elementos comparáveis em camadas superiores; por exemplo, um

objeto de dados (Camada de Aplicação) pode realizar um objeto de negócios (Camada de Negócios); ou um

artefato (Camada de Tecnologia) pode realizar um objeto de dados ou um componente de aplicativo (Camada de Aplicação).

3.4 O Framework Central ArchiMate

O Framework Central ArchiMate é um framework composto por nove células usado para classificar elementos da linguagem central ArchiMate. É composto por três aspectos e três camadas, conforme ilustrado na Figura 2. Esse framework é conhecido como o Framework Central ArchiMate.

É importante compreender que a classificação de elementos com base em aspectos e camadas é apenas uma abordagem geral. Elementos de arquitetura do mundo real não precisam ser estritamente confinados a um único aspecto ou camada, pois os elementos que conectam diferentes aspectos e camadas desempenham um papel central em uma descrição arquitetônica coerente. Por exemplo, antecipando um pouco as discussões conceituais posteriores, papéis de negócios atuam como elementos intermediários entre elementos “puramente comportamentais” e elementos “puramente estruturais”, e pode depender do contexto se um determinado software é considerado parte da Camada de Aplicação ou da Camada de Tecnologia.

Figura 2: Framework Central ArchiMate

A estrutura do framework permite modelar a empresa a partir de diferentes perspectivas, onde a posição dentro das células destaca as preocupações do interessado. Um interessado geralmente pode ter preocupações que abrangem múltiplas células.

As dimensões do framework são as seguintes:

• Camadas – os três níveis nos quais uma empresa pode ser modelada no ArchiMate – Negócios, Aplicação e Tecnologia (como descrito na Seção 3.3)
• Aspectos:

— OAspecto da Estrutura Ativa, que representa os elementos estruturais (os atores de negócios, componentes de aplicação e dispositivos que exibem comportamento real; ou seja, os

“sujeitos” da atividade)

— OAspecto do Comportamento, que representa o comportamento (processos, funções, eventos e serviços) realizados pelos atores; os elementos estruturais são atribuídos aos elementos comportamentais, para mostrar quem ou o que exibe o comportamento

— OAspecto da Estrutura Passiva, que representa os objetos sobre os quais o comportamento é realizado; esses são geralmente objetos de informação na Camada de Negócios e objetos de dados na Camada de Aplicação, mas também podem ser usados para representar objetos físicos

Esses três aspectos foram inspirados na linguagem natural, na qual uma frase possui um sujeito (estrutura ativa), um verbo (comportamento) e um objeto (estrutura passiva). Ao usar os mesmos construtos com os quais as pessoas estão familiarizadas em suas próprias línguas, a linguagem ArchiMate torna-se mais fácil de aprender e ler.

Como a notação ArchiMate é umalinguagem gráficaem que os elementos são organizados espacialmente, essa ordem não tem consequência na modelagem.

Um elemento composto, como mostrado na Figura 1, é um elemento que não necessariamente se encaixa em um único aspecto (coluna) do framework, mas pode combinar dois ou mais aspectos.

Observe que a linguagem ArchiMate não exige que o modelador use qualquer layout específico, como a estrutura deste framework; trata-se meramente de uma categorização dos elementos da linguagem.

3.5 O Framework Completo ArchiMate

O Framework Completo ArchiMate, conforme descrito nesta versão da norma, adiciona várias camadas e um aspecto ao Framework Central. Os elementos físicos são incluídos na Camada de Tecnologia para modelar instalações físicas, equipamentos, redes de distribuição e materiais. Assim sendo, esses também são elementos centrais. Os elementos estratégicos são introduzidos para modelar direções e escolhas estratégicas. Eles são descritos no Capítulo 7. O aspecto de motivação é introduzido em um nível genérico no próximo capítulo e descrito em detalhe no Capítulo 6. Os elementos de implementação e migração são descritos no Capítulo 12. O Framework Completo ArchiMate resultante é mostrado na Figura 3.

Figura 3: Framework Completo ArchiMate

A linguagem ArchiMate não define uma camada específica para informações; no entanto, elementos do aspecto de estrutura passiva, como objetos de negócios, objetos de dados e artefatos, são usados para representar entidades de informação. A modelagem de informações é suportada em todas as diferentes camadas ArchiMate.

3.6 Abstração na Linguagem ArchiMate

A estrutura da linguagem ArchiMate acomoda várias formas familiares de abstração e refinamento. Primeiramente, a distinção entre uma visão externa (caixa preta, abstraindo do conteúdo da caixa) e uma visão interna (caixa branca) é comum no design de sistemas. A visão externa representa o que o sistema deve fazer para seu ambiente, enquanto a visão interna representa como ele faz isso.

Em segundo lugar, a distinção entre comportamento e estrutura ativa é comumente usada para separar o que o sistema deve fazer e como o sistema faz isso dos constituintes do sistema (pessoas, aplicações e infraestrutura) que o realizam. Ao modelar novos sistemas, é frequentemente útil começar pelos comportamentos que o sistema deve executar, enquanto ao modelar sistemas existentes, é frequentemente útil começar pelas pessoas, aplicações e infraestrutura que compõem o sistema, e depois analisar em detalhe os comportamentos realizados por essas estruturas ativas.

Uma terceira distinção é entre os níveis de abstração conceitual, lógico e físico. Isso tem suas raízes na modelagem de dados: os elementos conceituais representam as informações que o negócio considera relevantes; os elementos lógicos fornecem estrutura lógica a essas informações para manipulação por sistemas de informação; os elementos físicos descrevem o armazenamento dessas informações; por exemplo, na forma de arquivos ou tabelas de banco de dados. Na linguagem ArchiMate, isso corresponde a objetos de negócios, objetos de dados e artefatos, juntamente com as relações de realização entre eles.

A distinção entre elementos lógicos e físicos também foi estendida à descrição de aplicações. O Metamodelo Empresarial TOGAF [4] inclui um conjunto de entidades que descrevem componentes e serviços de negócios, dados, aplicações e tecnologia para descrever conceitos de arquitetura. Os componentes lógicos são encapsulações independentes de implementação ou produto de dados ou funcionalidades, enquanto os componentes físicos são componentes de software tangíveis, dispositivos, etc. Essa distinção é capturada no framework TOGAF na forma de Blocos de Construção de Arquitetura (ABBs) e Blocos de Construção de Solução (SBBs). Essa distinção é novamente útil para avançar as arquiteturas empresariais de descrições de alto nível e abstratas para designs tangíveis e de nível de implementação. Observe que blocos de construção podem conter múltiplos elementos, que são tipicamente modelados usando o conceito de agrupamento na linguagem ArchiMate.

A linguagem ArchiMate possui três formas de modelar tais abstrações. Primeiro, conforme descrito em [6], elementos de comportamento, como funções de aplicação e tecnologia, podem ser usados para modelar componentes lógicos, já que representam encapsulações independentes de implementação de funcionalidades. Os componentes físicos correspondentes podem então ser modelados usando elementos de estrutura ativa, como componentes de aplicação e nós, atribuídos aos elementos de comportamento. Segundo, a linguagem ArchiMate suporta o conceito de realização. Isso pode ser melhor descrito trabalhando com a Camada de Tecnologia de cima para baixo. A Camada de Tecnologia define os artefatos físicos e o software que realizam um componente de aplicação. Também fornece um mapeamento para outros conceitos físicos, como dispositivos, redes, etc., necessários para a realização de um sistema de informação. A relação de realização também é usada para modelar tipos mais abstratos de realização, como a entre um requisito (mais específico) e um princípio (mais genérico), onde o cumprimento do requisito implica a adesão ao princípio. A realização também é permitida entre componentes de aplicação e entre nós. Dessa forma, é possível modelar um componente físico de aplicação ou tecnologia realizando um componente lógico de aplicação ou tecnologia, respectivamente. Terceiro, componentes de aplicação lógicos e físicos podem ser definidos como especializações de nível de metamodelo do elemento componente de aplicação, conforme descrito no Capítulo 14 (veja também os exemplos na Seção 14.2.2). O mesmo se aplica aos componentes de tecnologia lógicos e físicos do Metamodelo de Conteúdo TOGAF, que podem ser definidos como especializações do elemento nó (veja a Seção 14.2.3).

A linguagem ArchiMate intencionalmente não suporta a diferença entre tipos e instâncias. Ao nível de abstração de Arquitetura Empresarial, é mais comum modelar tipos e/ou exemplares em vez de instâncias. Da mesma forma, um processo de negócios na linguagem ArchiMate não descreve uma instância individual (ou seja, uma execução desse processo). Na maioria dos casos, um objeto de negócios é, portanto, usado para modelar um tipo de objeto (cf. uma classe UML®), do qual podem existir várias instâncias dentro da organização. Por exemplo, cada execução de um processo de aplicação de seguros pode resultar em uma instância específica do objeto de negócios de apólice de seguro, mas isso não é modelado na Arquitetura Empresarial.

3.7 Conceitos e sua Notação

A linguagem ArchiMate separa os conceitos da linguagem (ou seja, os constituintes do metamodelo) de sua notação. Grupos diferentes de interessados podem exigir notações diferentes para compreender um modelo ou visão de arquitetura. Nesse aspecto, a linguagem ArchiMate difere de linguagens como UML ou BPMN™, que possuem apenas uma notação padronizada. O mecanismo de perspectiva explicado no Capítulo 13 fornece os meios para definir visualizações orientadas aos interessados.

Embora a notação dos conceitos ArchiMate possa (e deva) ser específica para os interessados, a norma fornece uma notação gráfica comum que pode ser usada por arquitetos e outros que desenvolvem modelos ArchiMate. Essa notação é voltada para um público familiarizado com técnicas técnicas de modelagem existentes, como Diagramas de Relacionamento de Entidades (ERDs), UML ou BPMN, e, portanto, se assemelha a elas. No restante deste documento, salvo indicação em contrário, os símbolos usados para representar os conceitos da linguagem representam a notação padrão ArchiMate. Essa notação padrão para a maioria dos elementos consiste em um retângulo com um ícone no canto superior direito. Em vários casos, esse ícone por si só também pode ser usado como uma notação alternativa. Essa iconografia padrão deve ser preferida sempre que possível, para que qualquer pessoa que conheça a linguagem ArchiMate possa ler os diagramas produzidos nessa linguagem.

3.8 Uso de Aninhamento

O aninhamento de elementos dentro de outros elementos pode ser usado como uma notação gráfica alternativa para expressar algumas relações. Isso é explicado com mais detalhes no Capítulo 5 e na definição de cada uma dessas relações.

3.9 Uso de Cores e Dicas Notacionais

Nas imagens do metamodelo dentro desta norma, tons de cinza são usados para distinguir elementos pertencentes aos diferentes aspectos do framework ArchiMate, da seguinte forma:

• Branco para conceitos abstratos (ou seja, não instanciáveis)
• Cinza claro para estruturas passivas
• Cinza médio para comportamento
• Cinza escuro para estruturas ativas

Nos modelos ArchiMate, não há semânticas formais atribuídas às cores e o uso de cores é deixado ao modelador. No entanto, elas podem ser usadas livremente para enfatizar certos aspectos nos modelos. Por exemplo, em muitos dos modelos de exemplo apresentados nesta norma, as cores são usadas para distinguir entre as camadas do Framework Central ArchiMate, da seguinte forma:

• Amarelo para a Camada de Negócios
• Azul para a Camada de Aplicação
• Verde para a Camada de Tecnologia

Elas também podem ser usadas para ênfase visual. Um texto recomendado que fornece diretrizes é o Capítulo 6 de [1]. Além das cores, outras dicas notacionais podem ser usadas para distinguir entre as camadas do framework. Uma letra M, S, B, A, T, P ou I no canto superior esquerdo de um elemento pode ser usada para indicar um elemento de Motivação, Estratégia, Negócios, Aplicação, Tecnologia, Físico ou Implementação & Migração, respectivamente. Um exemplo dessa notação é mostrado no Exemplo 34.

A notação padrão também utiliza uma convenção com a forma dos cantos de seus símbolos para diferentes tipos de elementos, da seguinte forma:

• Cantos quadrados são usados para indicar elementos de estrutura
• Cantos arredondados são usados para indicar elementos de comportamento
• Cantos diagonais são usados para indicar elementos de motivação

[1]Observe que este foi chamado de “usado por” em versões anteriores do padrão. Para maior clareza, este nome foi alterado para “servindo”.

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