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