3 言語構造

本章では、ArchiMateエンタープライズアーキテクチャモデリング言語の構造について説明する。その標準的な要素および関係の詳細な定義と例は、第4章から第1章に続く。

3.1 言語設計に関する考慮事項

エンタープライズアーキテクチャのための一般的なメタモデルを開発する際の重要な課題は、個別のアーキテクチャ分野向けの言語の特異性と、システムを単なる相互関係のあるエンティティの集合として捉えるような、非常に一般的なアーキテクチャ概念のセットとの間でバランスを取ることである。

ArchiMate言語の設計は、比較的汎用的な概念の集合から出発した。これらの概念は、次の節で説明するように、異なるアーキテクチャ層での適用に向けて特化されている。言語に課せられた最も重要な設計制約は、可能な限り小さくする一方で、エンタープライズアーキテクチャモデリングの大多数のタスクに使用可能であるようにすることである。他の多くの言語は、すべてのユーザーのニーズを満たそうとしている。学習と使用の簡便さを重視して、ArchiMate言語は、実用的なケースの80％をモデル化するのに十分な概念に限定されている。

本規格は、ArchiMate言語の設計の詳細な根拠を説明していない。関心のある読者は、[1]、[2]、[3]を参照されたい。これらは、言語構築および設計に関する詳細な記述を提供している。

3.2 上位レベルの言語構造

図1は、言語の上位レベルの階層構造を示している：

• モデルとは、概念　－ 概念とは、要素または関係
• 要素とは、行動要素、構造要素、動機要素、または複合要素のいずれかである。

これらの概念は抽象的概念である。モデル内で直接使用することを意図していない。これを示すために、白い枠で囲み、ラベルは斜体で表示されている。図1で使用されている記法の説明は、第4章を参照のこと。

図1：ArchiMate概念の上位階層

3.3 ArchiMate言語のレイヤー構造

ArchiMateコア言語は、汎用的な要素とその関係の構造を定義しており、これらは異なるレイヤーで特化可能である。ArchiMateコア言語内には以下の3つのレイヤーが定義されている。

1. 「ビジネスレイヤー」は、顧客に提供されるビジネスサービスを示しており、これらはビジネスアクターによるビジネスプロセスによって組織内で実現される。
2. 「アプリケーションレイヤー」は、ビジネスを支援するアプリケーションサービスおよびそれらを実現するアプリケーションを示す。
3. 「テクノロジー・レイヤー情報技術と運用技術の両方を含みます。たとえば、アプリケーション世界およびビジネス層を支援するための処理、ストレージ、通信技術をモデル化でき、施設、物理的設備、材料、および配送ネットワークを用いて運用技術または物理的技術をモデル化できます。

異なるレイヤー内のモデルの一般的な構造は類似しています。同じ種類の要素と関係が使用されますが、その正確な性質や粒度は異なります。次の章では、汎用メタモデルの構造が提示されます。第8章、第9章、第10章では、これらの要素を特定のレイヤーに特化させることで、特定のレイヤーに特有の要素を取得します。

サービス指向に合わせて、レイヤー間で最も重要な関係は「サービス提供」関係によって形成されます。[1]関係であり、あるレイヤーの要素が他のレイヤーのサービスによってどのように提供されているかを示します。（ただし、サービスは他のレイヤーの要素にのみ提供されるわけではないため、同じレイヤー内の要素にも提供できる点に注意してください。）第二の種類のリンクは実現関係によって形成されます。下位レイヤーの要素は、上位レイヤーの同等の要素を実現する可能性があります。たとえば、

「データオブジェクト」（アプリケーションレイヤー）が「ビジネスオブジェクト」（ビジネスレイヤー）を実現する可能性がある。あるいは、

「アーティファクト」（技術レイヤー）が「データオブジェクト」または「アプリケーションコンポーネント」（アプリケーションレイヤー）のいずれかを実現する可能性がある。

3.4 ArchiMateコアフレームワーク

ArchiMateコアフレームワークは、ArchiMateコア言語の要素を分類するために使用される9つのセルから構成されるフレームワークです。図2に示すように、3つの側面と3つのレイヤーから構成されています。これをArchiMateコアフレームワークと呼びます。

側面とレイヤーに基づく要素の分類はあくまで全体的なものであることを理解することが重要です。現実のアーキテクチャ要素は、必ずしも1つの側面やレイヤーに厳密に限定される必要はありません。異なる側面やレイヤーをつなぐ要素は、整合的なアーキテクチャ記述において中心的な役割を果たすからです。たとえば、後の概念的議論の前に進んで述べると、ビジネスロールは「純粋に行動的」な要素と「純粋に構造的」な要素の間の仲介要素として機能し、あるソフトウェアがアプリケーションレイヤーか技術レイヤーの一部と見なされるかどうかは、文脈によって異なります。

図2：ArchiMateコアフレームワーク

このフレームワークの構造により、ステークホルダーの関心を強調するさまざまな視点から企業をモデル化できます。ステークホルダーは通常、複数のセルにわたる関心を持つことができます。

このフレームワークの次元は以下の通りです：

• レイヤー – ArchiMateで企業をモデル化できる3つのレベル – ビジネス、アプリケーション、技術（3.3節で説明）
• 側面：

— アクティブ構造側面、これは構造的要素（実際の行動を示すビジネスアクター、アプリケーションコンポーネント、デバイス）を表します。すなわち、

「行動の主体」

— 行動側面、これはアクターによって行われる行動（プロセス、機能、イベント、サービス）を表します。構造的要素は行動的要素に割り当てられ、誰または何が行動を示しているかを示します。

— パッシブ構造側面、これは行動が行われる対象を表します。これらは通常、ビジネスレイヤーの情報オブジェクトおよびアプリケーションレイヤーのデータオブジェクトですが、物理的オブジェクトを表すためにも使用できます。

この3つの側面は、文に主語（アクティブ構造）、動詞（行動）、目的語（パッシブ構造）がある自然言語にインスパイアされています。人々が自分の言語で慣れている構造を使用することで、ArchiMate言語は学びやすく、読みやすくなります。

ArchiMate表記は図式的言語であり、要素が空間的に配置されるため、この順序はモデル化において重要ではありません。

図1に示すように、複合要素とは、フレームワークの単一の側面（列）に必ずしも当てはまらない要素であり、2つ以上の側面を組み合わせる可能性があります。

ArchiMate言語は、モデル作成者がこのフレームワークの構造のような特定のレイアウトを使用することを要求しないことに注意してください。これは、言語要素の分類にすぎません。

3.5 ArchiMateフルフレームワーク

この標準のこのバージョンで説明されているArchiMateフルフレームワークは、コアフレームワークに複数のレイヤーとアスペクトを追加しています。物理的要素は、物理施設や設備、配布ネットワーク、素材をモデル化するためにテクノロジー層に含まれます。これにより、これらもコア要素となります。戦略的要素は、戦略的方針や選択をモデル化するために導入されています。これらは第7章で説明されています。動機に関するアスペクトは次の章で一般的なレベルで導入され、第6章で詳細に説明されています。実装および移行要素は第12章で説明されています。その結果としてのArchiMateフルフレームワークは図3に示されています。

図3：ArchiMateフルフレームワーク

ArchiMate言語は情報用の特定のレイヤーを定義していませんが、ビジネスオブジェクト、データオブジェクト、アーティファクトなどの受動的構造アスペクトの要素が、情報エンティティを表すために使用されます。情報モデル化は、ArchiMateの異なるレイヤーでサポートされています。

3.6 ArchiMate言語における抽象化

ArchiMate言語の構造は、いくつかの一般的な抽象化および精緻化の形式を扱うことができます。まず、外部（ブラックボックス、箱の中身を抽象化）と内部（ホワイトボックス）の視点の区別は、システム設計において一般的です。外部視点は、システムが環境に対して行うべきことを示し、内部視点は、それがどのように行われるかを示します。

第二に、行動とアクティブ構造の区別は、システムが行うべきこととその方法を、それを実行するシステム構成要素（人、アプリケーション、インフラ）から分離するために一般的に使用されます。新しいシステムをモデル化する際には、システムが実行すべき行動から始めると便利なことが多く、既存のシステムをモデル化する際には、システムを構成する人、アプリケーション、インフラから始め、その後、これらのアクティブ構造が実行する行動を詳細に分析すると便利です。

第三の区別は、概念的、論理的、物理的抽象レベルの違いです。これはデータモデリングに由来しています。概念的要素は、ビジネスが関心を持つ情報を表します。論理的要素は、情報システムによる操作を可能にするために、この情報を論理的に構造化します。物理的要素は、この情報の保存方法を記述します。たとえば、ファイルやデータベーステーブルの形式で。ArchiMate言語では、これに対応してビジネスオブジェクト、データオブジェクト、アーティファクト、およびそれらの間の実現関係が使用されます。

論理的要素と物理的要素の区別は、アプリケーションの記述にも適用されています。TOGAFエンタープライズメタモデル[4]は、ビジネス、データ、アプリケーション、テクノロジーのコンポーネントおよびサービスを記述して、アーキテクチャ概念を表現するためのエンティティのセットを含んでいます。論理的コンポーネントは、実装や製品に依存しないデータまたは機能のカプセル化であり、物理的コンポーネントは、実際のソフトウェアコンポーネント、デバイスなどです。この区別は、TOGAFフレームワークではアーキテクチャビルディングブロック（ABB）とソリューションビルディングブロック（SBB）の形で捉えられています。この区別は、エンタープライズアーキテクチャを高レベルの抽象的記述から、実際の実装レベルの設計へと進める際にも有用です。ビルディングブロックには複数の要素が含まれる可能性があることに注意してください。これらは通常、ArchiMate言語のグループ化概念を使用してモデル化されます。

ArchiMate言語は、このような抽象化をモデル化するための3つの方法を持っています。第一に、[6]で説明されているように、アプリケーション機能やテクノロジー機能などの行動要素を使用して論理的コンポーネントをモデル化できます。なぜなら、これらは実装に依存しない機能のカプセル化を表しているからです。対応する物理的コンポーネントは、行動要素に割り当てられたアクティブ構造要素（アプリケーションコンポーネントやノードなど）を使用してモデル化できます。第二に、ArchiMate言語は実現の概念をサポートしています。これは、テクノロジー層から上へと進んで説明するのが最も適切です。テクノロジー層は、アプリケーションコンポーネントを実現する物理的アーティファクトやソフトウェアを定義します。また、情報システムの実現に必要なデバイス、ネットワークなどの他の物理的概念へのマッピングも提供します。実現関係は、より抽象的な実現、たとえば（より具体的な）要件と（より一般的な）原則との間の実現などもモデル化するために使用されます。要件の満足は原則の遵守を意味するため、その関係が成立します。実現は、アプリケーションコンポーネント間およびノード間でも許容されます。これにより、物理的アプリケーションまたはテクノロジー・コンポーネントが論理的アプリケーションまたはテクノロジー・コンポーネントを実現することをモデル化できます。第三に、論理的および物理的アプリケーションコンポーネントは、第14章で説明されているように、アプリケーションコンポーネント要素のメタモデルレベルでの特殊化として定義できます（14.2.2節の例も参照）。TOGAFコンテンツメタモデルの論理的および物理的テクノロジー・コンポーネントについても同様に、ノード要素の特殊化として定義できます（14.2.3節を参照）。

ArchiMate言語は意図的に、型とインスタンスの違いをサポートしていません。エンタープライズアーキテクチャの抽象レベルでは、インスタンスよりも型や例（エクセムプラ）をモデル化することが一般的です。同様に、ArchiMate言語におけるビジネスプロセスは、個別のインスタンス（つまり、そのプロセスの1回の実行）を記述するものではありません。ほとんどの場合、ビジネスオブジェクトはオブジェクト型（cf.UML®クラス）、その組織内に複数のインスタンスが存在する可能性があります。たとえば、保険申請プロセスの各実行は、保険契約ビジネスオブジェクトの特定のインスタンスを生成する可能性がありますが、これはエンタープライズアーキテクチャではモデル化されません。

3.7 概念とその表記法

ArchiMate言語は、言語概念（すなわちメタモデルの構成要素）とその表記法を分離しています。異なるステークホルダー群は、アーキテクチャモデルやビューを理解するために、異なる表記法を必要とする場合があります。この点で、ArchiMate言語はUMLやBPMN™のように、唯一の標準化された表記法を持つ言語とは異なります。第13章で説明されているビューのメカニズムが、このようなステークホルダー指向の可視化を定義する手段を提供します。

ArchiMate概念の表記法は（そして、すべきである）、ステークホルダーに特化したものである可能性がありますが、標準は、アーキテクトやArchiMateモデルを開発する他の人々が使用できる共通のグラフィカル表記を提供しています。この表記法は、エンティティ関係図（ERD）、UML、BPMNなどの既存の技術的モデリング技法に慣れている対象者を対象としており、それらに似ています。この文書の残りの部分では、特に断りのない限り、言語概念を表すために使用される記号は、ArchiMate標準表記を表します。ほとんどの要素に対する標準表記は、右上にアイコンを含むボックスです。いくつかのケースでは、このアイコン単体も代替表記として使用できます。可能な限り、この標準的なアイコン表記を優先するべきです。これにより、ArchiMate言語を知っている誰もが、この言語で作成された図を読み取ることができます。

3.8 ネスティングの使用

要素を他の要素の中にネストすることで、関係を表現するための代替的なグラフィカル表記として使用できます。これは第5章およびこれらの関係の定義で詳しく説明されています。

3.9 色と表記的ヒントの使用

この標準内のメタモデル図では、グレーの濃淡を使って、ArchiMateフレームワークの異なるアスペクトに属する要素を区別しています。以下の通りです：

• 白色：抽象的（すなわち、インスタンス化できない）概念
• 薄いグレー：受動的構造
• 中程度のグレー：行動
• 濃いグレー：アクティブ構造

ArchiMateモデルでは、色に正式な意味合いは割り当てられておらず、色の使用はモデル作成者に任されています。しかし、モデル内の特定の側面を強調するために自由に使用できます。たとえば、この標準で提示されている多くの例モデルでは、色がArchiMateコアフレームワークのレイヤーを区別するために使用されています。以下の通りです：

• 黄色：ビジネス層
• 青色：アプリケーション層
• 緑色：テクノロジー層

また、視覚的な強調にも使用できます。ガイドラインを提供する推奨テキストは[1]の第6章です。色に加えて、他の表記的ヒントを使用して、フレームワークのレイヤーを区別できます。要素の左上隅にM、S、B、A、T、P、またはIという文字を配置することで、それぞれ動機、戦略、ビジネス、アプリケーション、テクノロジー、物理、実装および移行要素を示すことができます。この表記法の例は、例34に示されています。

標準的な表記法は、異なる要素タイプに対して、記号の角の形状に関する慣例を使用しています。以下の通りです：

• 角が四角形のものは、構造要素を示すために使用されます
• 角が丸いものは、行動要素を示すために使用されます
• 角が斜めのものは、動機要素を示すために使用されます

[1]以前のバージョンでは「使用される」呼ばれていました。明確さを図るため、この名称は「提供する」に変更されました。

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