ArchiMateの例示ビュー：完全なギャラリー – 动機、戦略、ビジネス、アプリケーション、テクノロジーおよび移行

フレームワークビュー

フレームワークビュー。

このビューは、すべての開発的側面および関連する図の構築のためのフレームワークを表しています。状況に応じてこのビューを変更できます。したがって、このビューは図間のナビゲーションに使用できます。このビューのバージョンはArchiMate（3）フレームワークから適用されています。動機は「側面」ではなく「レイヤー」として導入されています。

動機の視点

動機の視点

動機の視点。

このビューは、組織およびそのエンタープライズアーキテクチャの設計または変更を導く動機や駆動要因を分析するために使用できます。これらの動機分析は、組織内のすべての変更活動やビジネス変革の出発点となります。このビューは開発作業のビジョンを表しており、対象範囲やスケールが組織全体、またはその一部（例：事業ライン）または単一のプログラムやプロジェクト（ソリューションレベル）をカバーするかを示します。注：Outcome（またはその他のArchiMate要素）に値を追加することで、実際の付加価値を示すことができます！

動機の要素は、ビジネス動機モデル（BMM）に基づいています[仕様 v.1.3, 2015, OMG]。

ミッション – ビジョン – 価値観ビュー

ミッション – ビジョン – 価値観。

このビューは、組織のミッション、ビジョン、およびコアバリューを表すために使用できます。ミッションは、たとえば「組織の目的とは何か、実際に何をしているか、または何をしようとしているか、そして存在する主な理由は何か？」を示します。ビジョンは、組織が目指す将来の状態です。コアバリューはビジョンを支え、文化を形成し、組織の価値観を反映します。組織のビジョンを実現するためには、戦略的目標を達成する必要があります。

参考文献：Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) ArchiMateによる戦略のモデリング。

戦略的価値マップビュー

価値マップ – 戦略マップビュー。

このビューは、組織の戦略を可視化するために使用できます。このビューには戦略的価値要素が含まれており、すべての開発活動は、直接的または間接的に戦略的価値要素から導かれる必要があります。戦略的価値を可視化することで、実際の戦略実行に関連するすべての要素を追跡することが可能になります。このビューにより、戦略を具体的なものにできます：可視化し、伝達し、現実と結びつけることができます。

ステークホルダー分析ビュー

ステークホルダー分析ビュー。

このビューは、ビジネス開発のためのステークホルダー分析に使用できます。変化の駆動要因とは何か？まず、関連するステークホルダーを特定し、それらの関心に一致する変化の駆動要因を決定します。「アセスメント」の概念を使用して、SWOT（強み、弱み、機会、脅威）アプローチなどに基づいて駆動要因をより詳しく分析できます。通常、異なる視点から異なるステークホルダーのビューを作成できます。大きな図を小さな図に分割するもう一つの理由は、図をコンパクトで読みやすく保つためです — 簡単にするためです。

ステークホルダーの視点

ステークホルダーの視点。

このビューは、ステークホルダーの駆動要因をビジネス目標に結びつけるために使用できます。目標は組織の開発における重要な要素です。すべての後続の要素は、すべての変更活動の主要な駆動要因に遡るべきです。

原則ビュー

原則ビュー。

リスクおよびセキュリティビュー

リスクおよびセキュリティビュー。リスクおよびセキュリティの概念をArchiMateにマッピングする。セキュリティおよびデータ保護の問題はリスク管理の一部です。このモデリングアプローチは両方をカバーしています。

参考文献：

• ArchiMate®言語を用いたエンタープライズリスク管理およびセキュリティのモデリング方法、The Open Group、文書番号：W172、2017。
• ArchiMate®言語を用いた企業リスク管理およびセキュリティのモデル化、The Open Group、2015年。

SWOT分析ビュー

SWOT分析ビュー。

目標ビュー

目標ビュー（価値要素を含む）。

目的と重要な成果

OKRパターン。

OKRは、目的を定義し、成果を追跡するための一般的なマネジメント戦略です。測定可能な目標の周囲で整合性と関与を促進します。OKRには2つの重要な要素があります：達成したい目的と、目的の達成をどのように測定するかを示す重要な成果です。

目的：

• 達成したいことの記憶に残る、定性的な記述です。目的は短く、インスピレーションを与え、参加を促すものでなければなりません。目的はチームを動機づけ、挑戦させるものでなければなりません。

重要な成果：

• 目的への進捗を測定するための指標の集合です。各目的に対して2～5つの重要な成果を持つべきです。多すぎると、誰も覚えていなくなるでしょう。

以下にOKRの別のバージョンを示します。

OKRパターン（2）。

戦略視点

戦略レイヤービュー

戦略ビュー

戦略ビュー。

ArchiMateバージョン3は、「行動計画」、「能力」、「リソース」など、ビジネス戦略に関連する概念をサポートしています。これらは組織のビジネス戦略をモデル化するために使用できます。このビューの価値と重要性は、組織の目標が戦略とリンクされ、能力を通じてエンタープライズアーキテクチャとどのようにリンクされるかを示している点にあります。このビューは、「目的ベースの戦略モデリング」（Azevedo他、2015）を適用するのに使用でき、目的が階層を形成し、上位の目的が下位の目的に分解できるようにします。

ビジネス戦略ビュー

ビジネス戦略。

ビジネス動機モデル（BMM）ビュー

ビジネス動機モデル（BMM）ビュー。

要件ビュー

要件ビュー。

このビューは、戦略的目標に基づいて要件を収集するために使用できます。これにより、戦略と実現がリンクされます。戦略は実行にまで追跡可能になります。

戦略から能力へのビュー

戦略から能力へのビュー。

このビューは、能力ベースの計画（CBP）などの目的に使用できます。また、図に示すように、「ドライバー」や「目標」といった他のArchiMateの概念にも使用できます。このビューは戦略計画（および実行）を支援するために使用できます。したがって、このビューは「戦略から能力へのフェーズ」に使用でき、IT4ITの「戦略からポートフォリオ」に含まれる可能性があります。

能力マップビュー

能力マップビュー。

このビューは、組織の能力を概観するのに使用できる。すなわち、組織が行っていること、または行えることである。

能力計画ビュー

能力計画ビュー。

このビューは、能力ベース計画（CBP）の目的などに使用できる。すなわち「戦略とエンタープライズアーキテクチャのつながり」である。このビューは、戦略を必要な能力にマッピングしたり、能力をリソースや他の構成要素にマッピングするのに使用できる。

能力実現ビュー

能力実現ビュー。

能力実現ビュー 2

能力がどの要素によって実現されるかを定義する別のビュー…

能力実現ビュー 2。

バリューストリームビュー

バリューストリームビュー（パターン）。

注意！「有向関連」はバリューチェーン／バリューストリームの開始部で使用される。バリューストリームは、価値の「段階」で構成されることがある。同様に、全体的で高レベルのバリューストリームは「バリューチェーン」となることがあり、そのバリューチェーンはさらに複数のバリューストリームで構成される。たとえば、IT4IT（リンク）は、以下の4つのバリューストリームからなるバリューチェーンを導入している：ポートフォリオ戦略、需要展開、リクエスト対応、検出から修正（リンク).

バリューストリーム－能力クロスマッピングビュー

下に、バリューデリバリー・チェーンの簡単な例を示す。バリューチェーン、バリューネットワーク、バリューストリームは、ArchiMate 3.1版に含まれるArchiMateのバリューストリーム要素を使用してモデル化できる。

アイデアから生産へのバリューチェーン例ビュー。

バリューデリバリー・チェーン。これは、機能がバリューストリームを支援（サービス提供）する仕組みを示す拡張例である。このビューは、組織が何をしているか（ビジネスモデル）、なぜ能力が必要なのか、そしてそれらが価値創造とどのように関連しているかを定義するのに使用できる。

このビューは、Lean EAフレームワーク（LEAF）の参照実装（リンク）に含まれている。「バリューストリーム」、「バリューデリバリー・チェーン」に移動する。

ビジネスモデルキャンバスビュー

ビジネスモデルビュー。

これはA.オスターウァルダーのビジネスモデルキャンバス（BMC）の基本形であるが、状況に応じて変更できる。また、「サービスモデルキャンバス」や「リーンキャンバス」などのバージョン化されたアプローチもある。BMCは、ビジネスモデルの設計やイノベーションなどに使用できる。

ArchiMateを用いたBMCのモデリングは、「ビジネスニーズから設計仕様への要件のトレースを支援する。これにより、ビジネスモデルの変更がアーキテクチャ設計に与える影響を明らかにすることができる。」[LO Meertensら]

全体的な開発には、戦略およびビジネスモデル分析のための組み込み型アーキテクチャ的サポートが含まれます。これにより、ビジネスアナリストや開発者は、たとえばビジネスモデルが戦略をどのように支援しているか、またビジネスモデルが組織にどのように適応しているか、逆に組織がビジネスモデルにどのように影響しているかを観察できます。

BMCがモデル化ツールでモデル化された場合、このアプローチの利点は、BMCのすべての要素を同じモデルリポジトリ内の他のビューで使用できることです。ビジネスモデルが変更されたとき、すべての変更が即座に可視化されます。ビジネスモデル作成者は、新しい要素（たとえばサービス）を作成したり、リポジトリ内のすべての既存の要素（たとえば組織単位やリソース）を利用できます。

コンセプトキャンバスビュー

コンセプトキャンバス。BMCは、以下の図に示すように、さまざまなバリエーションを持つことができます。このコンセプトキャンバスのレイアウトは、ArchiMateのレイヤードアプローチと整合しています。

ビジネス視点

ビジネスアーキテクチャレイヤービュー。

ビジネスサービスマップビュー

ビジネスサービスビュー。

このビューは、組織のビジネスサービスの概要を提供します。このビューは、経営管理のための「サービスカタログ」または「サービスポートフォリオ」として使用できます。組織が顧客に提供するビジネスサービスを特定することは非常に重要です。さらに、ビジネスサービスは、すべての下位の組織プロセスや構造をモデル化する出発点となります。したがって、ビジネスサービスは企業アーキテクチャにおいて最も重要な要素の一つです。

ビジネスプロセスマップビュー

ビジネスプロセスビュー。

このビューは、組織のビジネスプロセスの概要を提供する「プロセスマップ」として使用できます。

ビジネスプロセス協働ビュー

ビジネスプロセス協働ビュー。

このビューは、たとえば運用モデルをモデル化するために使用できます。

ビジネスアクター・マップビュー

ビジネスアクター・ビュー。

ビジネスアクターは、a) 内部または b) 外部のいずれかです。内部のビジネスアクターは、たとえば組織単位を指し、外部のビジネスアクターは、顧客、ビジネスパートナー、または組織と協働するその他のステークホルダー集団（たとえば公共部門機関やその他の統治機関）を指します。

ビジネスアクター協働ビュー

ビジネスアクター協働ビュー。

以下の2つのユースケースがあります：

1. 社内ビュー：内部のビジネスアクターがどのように協働し、情報のやり取りを行うかを説明するビジネスアクター協働視点。
2. 社外ビュー：組織が運営する環境を描いたエコシステム視点。エコシステムとは、協働的な相互作用を通じて連携する組織およびビジネスパートナーのネットワークです。サプライヤー、下請け業者、その他のB2Bパートナー、顧客などがあります。

ビジネスプロセスビュー

ビジネスプロセスビュー。

このビジネスプロセスビューは、「1つ以上のビジネスプロセス（またはその一部）の高レベルな構造および構成、サービスの提供、アクターが役割に割り当てられ、ビジネスプロセスが情報を利用する」ことを提供します [ArchiMate 2.1仕様]。プロセス図には、プロセスフローにおける「分岐」および「合流」をモデル化するために使用される「ジャンクション」要素が含まれます。

以下の図は高レベルなプロセスビューを示しています。これは、上記のバリューストリーム図に示すように、ビジネスモデルから導き出された運用モデルに基づいています。

アイデアから製品化プロセス。

SIPOC（サプライヤー、入力、プロセス、出力、顧客）

SIPOC。

シックスシグマのツールであるSIPOC（サプライヤー、入力、プロセス、出力、顧客）は、すべてのプロセスに共通する要素を定義するために使用できます。これはビジネスケースを分析するためのシンプルなツールであり、顧客がどのような価値を受け取り、どのように受け取るかを示します。

ビジネスプロセスをビジネスロールをプロセスの「スイムレーン」として表示する – 層状アプローチ

ビジネスプロセススイムレーンビュー（パターン）2.0。

「ビジネスロールA」は顧客を表し、最上位の「スイムレーン」は顧客ジャーニーの経路を表します。

注意！プロセスステップ（活動）は、ビジネスロール（「スイムレーン」として可視化）の内部にネストされています。つまり、これらのビジネスロールがこれらのビジネスプロセス／プロセスステップに割り当てられていることを意味します。したがって、このビューはビジネスプロセスビューと層状ビューの組み合わせです。

以下のバージョンは情報およびデータのフロー（フロー関係）を示しています。最上位の「スイムレーン」は顧客ジャーニーの経路（トリガー関係で関連付けられた活動）を表します。

ビジネスプロセススイムレーンビュー（パターン）2.0（情報フロー）。

以下のバージョンはサービス設計アプローチを表しています。最上位の「スイムレーン」（ロールA）は顧客ジャーニーの経路を表し、ビジネスサービス（1と2）を通じて組織（ロールBとC）と接続されています。

ビジネスプロセススイムレーンビュー（パターン）2.0（サービス）。

層状ビジネスプロセスビュー

層状プロセスビュー。

このビューは、手動および自動ステップを含むビジネスプロセスをモデル化するために使用できます。

顧客ジャーニーマップビュー

顧客ジャーニーを高レベルで分析する場合、このバージョンは動機および戦略要素を使用して作成されます。

顧客ジャーニーマップ（高レベル）。

顧客サービス経路をより詳細に分析する場合、このバージョンはビジネス層およびアプリケーション層（コア）の要素を使用して作成されます。

顧客ジャーニービュー（例）1.0。

この顧客中心のビューは顧客体験に焦点を当てています。「サービス設計」に関連するこの「外部からのアプローチ」は、サービスや製品が顧客に価値を提供するために作成されるという重要な側面を強調しています。また、組織自体にも間接的に価値をもたらします。顧客ジャーニーの経路は、複数のアプリケーションサービスおよびアプリケーションにまたがる顧客価値フローを可視化するために使用できます。

サービスブループリントビュー

サービスブループリントビュー1（サービスとフロー）

このビューは顧客およびサービス中心ですが、サービスの「内部からの側面」にも重点を置いています。このアプローチにより、サービス駆動型開発は設計されるサービスに潜在的な行動的および構造的影響を特定できます。したがって、このビューはプロセスおよび機能的側面を通じて顧客体験駆動型アプローチを補完します。

このビューにはいくつかのバリエーションがあります。上記の例は、層間および要素間の情報フローに焦点を当てています。

ユーザーストーリービュー

ユーザーストーリービュー。

このビューはユーザーストーリーを可視化するために使用できます。

クラウドサービスモデルビュー

クラウドサービスモデルビュー。

情報ビュー

情報ビュー。

情報は以下の通り、異なる抽象化レベルでモデル化できます：a) 概念的、b) 論理的、c) 物理的レベル。上図はこれらの抽象化レベルを示しています。

概念的データモデルビュー

概念的データモデルビュー。

EAの情報アーキテクチャには、ビジネスプロセスで使用されるビジネスオブジェクト、すなわちコンセプトが含まれる。これらのコンセプトおよびそれらの関係は、概念的データモデルで表現できる。

「サービス」コンセプト

サービスコンセプト。

サービスコンセプトはしばしば問題を引き起こし、さまざまな方法で解釈されることがある。関与するサービスの種類を明確に区別するために、接頭辞を付けることが良い実践である：ビジネスサービス、アプリケーションサービス、またはテクノロジーサービス。ITILによれば、ITサービスは生産サービスに関連している。このように。ITサービスはアプリケーションサービスに最も近い対応関係を持つ。

サービス対製品

製品ビュー。

製品コンセプトは、サービスをグループ化するための複合要素として使用できる。ArchiMate仕様によれば：

「製品は、一貫性のあるサービスおよび／または受動的構造要素の集合を表し、契約／合意セットとともに、（内部または外部の）顧客に全体として提供される。」

「製品は、ビジネスサービス、アプリケーションサービス、テクノロジーサービス、ビジネスオブジェクト、データオブジェクトおよびテクノロジーオブジェクト、および契約を集約または構成することができる。したがって、製品はビジネス層以外のレイヤーからの要素を集約または構成することができる。」

「製品に関連付けられる価値がある場合がある。製品名は通常、顧客とのコミュニケーションで使用される名前であるか、より一般的な名詞（例：『旅行保険』）である場合がある。」

アプリケーション視点

アプリケーションアーキテクチャレイヤービュー。

アプリケーションサービスマップビュー

アプリケーションサービスビュー。

アプリケーションマップビュー

アプリケーションマップビュー。

アプリケーションポートフォリオ。ここでは、アプリケーションをビジネスユニットごとにグループ化できる。

アプリケーション協働ビュー（データフロー）

アプリケーション協働ビュー。

アプリケーション統合ビュー（動的関係）

アプリケーション間でのデータの切り替えをモデル化するためのいくつかの代替的な方法が、以下の例（1～10）に示されている。

• 「アプリケーションA」は、「アプリケーションB」によって要求されたデータオブジェクト「A-1」を所有している。
• データは「アプリケーションA」から「アプリケーションB」へ流れている。
• 「アプリケーションA」は、「アプリケーションB」が使用するサービス「A-1」を実現している。
• 実際には、「アプリケーションB」はアプリケーションインターフェース「A-1」を要求し、応答を得る…

アプリケーション統合ビュー。

アプリケーション構造ビュー

このビューは、アプリケーションの主要な構造およびそのサブコンポーネントと関連データを設計または理解するのを支援する。図は、構築中のアプリケーションシステムの構造を分解してモジュール化／分解を示すために使用できる。すなわち、サブシステム／サブコンポーネントとは何か、それらが提供するアプリケーションサービス（またはアプリケーションインターフェース）とは何かを示す。

アプリケーション構造ビュー。

アプリケーションサービス（上図）は、構造的インターフェース（下図のGUIおよび／またはAPI）によって提供される行動機能であることに注意してください。アプリケーションサービスとアプリケーションインターフェースは「同一の硬貨の両面」です。

アプリケーション構造ビュー 2。

アプリケーションアーキテクチャビュー

このビューでは、アプリケーションとアプリケーションモジュールの両方が同じビューに存在するため、EAレベルとソリューションレベルのアプローチが混在しています。

アプリケーションアーキテクチャ。

アプリケーションコンポーネントモデル（CM）

アプリケーションコンポーネントモデル 0-n は、以下の異なる抽象度の図から構成されるアプリケーションアーキテクチャモデリング手法です：

• CM-0レベルでは、図は対象アプリケーションがその環境とどのように相互作用するか、および隣接するアプリケーションやユーザーとの相互作用がどのようなものかを記述します。対象アプリケーションはブラックボックスとして記述されます。
• CM-1レベルでは、対象アプリケーションがモジュール（主要コンポーネント）に分解され、各モジュールが提供および要求するアプリケーションサービス（またはアプリケーションインターフェース）が示されます。対象アプリケーションはホワイトボックスとして記述されます。
• CM-2レベルでは、モジュールがサブコンポーネントに分解されます。（必要なレベル数は状況により異なります。）

以下のアプリケーションコンポーネントモデル（CM）図は、アプリケーションコンポーネントとアプリケーションサービスから構成されています。状況に応じて、アプリケーションサービスの代わりにアプリケーションインターフェースを使用することもできます。常に、目的に合ったモデリングスタイルを使用し、十分な情報を提供し価値を加える要素のみをモデル化することが重要です。これはモデラー次第です——機能的側面を強調するか、より具体的に正確な名前を持つ実際のインターフェースなどをモデル化するかの選択です。

以下のコンポーネントモデル図は、アプリケーションコンポーネントとアプリケーションサービスから構成されています。状況に応じて、アプリケーションサービスの代わりにアプリケーションインターフェースを使用することもできます。

アプリケーションコンポーネントモデル – 0（CM-0）

アプリケーションコンポーネントモデル – 0。

コンポーネントモデル – 0（CM-0）レベル（上図）は、対象アプリケーションと隣接アプリケーションとの相互作用を示しています。関連するすべてのアプリケーションサービス（またはアプリケーションインターフェース）が導入されます。レベル0の図は、企業アーキテクチャレイヤのコンポーネントとそのサービスから構成され、対象アプリケーションが中央に位置します。

アプリケーションコンポーネントモデル – 1（CM-1）

アプリケーションコンポーネントモデル – 1。

コンポーネントモデル – 1（CM-1）レベル（上図）は、対象アプリケーションがモジュール（または主要コンポーネント）にどのように分解されるか、および各モジュールが実現するアプリケーションサービス（またはアプリケーションインターフェース）を示しています。注意！外部アプリケーションはこのレベルから除外できますが、そのサービス（またはインターフェース）は表示されます。より低いレベルの要素を表示する場合、より高いレベルの要素を省略する必要がある場合があります——簡潔さのため：図が読みやすいように保つこと。

アプリケーションコンポーネントモデル – 2（CM-2）

アプリケーションコンポーネントモデル – 2。

コンポーネントモデル – 2（CM-2）レベル（上図）は、対象アプリケーションのモジュールがサブコンポーネントで構成され、それらがどのように相互作用するかを示しています。

アプリケーション機能ビュー

アプリケーション機能の分解：システムにはどのような機能が含まれており、どのようなアプリケーションサービスを提供するか？

アプリケーション機能ビュー。

アプリケーションプロセスビュー

アプリケーションプロセスビュー。

アプリケーションプロセスビュー – ネスティング。

アプリケーションプロセスビュー – 内部。

アプリケーションコンポーネントシーケンス図ビュー

シーケンス図はArchiMateの完全な範囲には含まれませんが、UMLの範囲内です。しかし、以下の図のようにArchiMateを使用して、アプリケーションコンポーネントが実行するアクションの順序をモデル化できます。

アプリケーションシーケンスビュー。

動的関係「トリガー」と「フロー」を使用して、アプリケーションコンポーネント間の動的挙動をモデル化できます。このビューのレイアウトは、UMLシーケンス図の配置に似ています。

アプリケーションコンポーネントシーケンス図ビュー 2

このバージョン（以下）は、ArchiMateを使用してアプリケーションコンポーネントの内部部品が実行するアクションの順序をモデル化する方法を示しています。内部部品には、たとえば a) 行動プロセスまたは関数、および b) 構造的サブコンポーネントが含まれます。これらは、アプリケーションプロセス、アプリケーション関数、アプリケーションコンポーネント要素でモデル化されます。ここではこれらが代替案として示されています。

アプリケーションシーケンスビュー（2）。

このシーケンス図（上）における処理の流れ：

1. アプリケーションコンポーネント「A」のサブプロセス「X」は、パラメータ「A」を含むリクエストメッセージをアプリケーションBに送信する。
2. アプリケーションコンポーネント「B」のサブプロセス「B-1」は受信したリクエストを受信し、その後（同期的に）アプリケーションコンポーネントCを呼び出し、アプリケーション関数「Y」がリクエストを受信し、いくつかの処理を実行して応答する。
3. アプリケーションコンポーネント「B」の別のサブプロセス「B-2」は、パラメータを含むメッセージをアプリケーションコンポーネントDに送信し、確認応答を受信する。アプリケーションコンポーネント「D」には処理を実行するサブコンポーネントが含まれる。
4. アプリケーションコンポーネント「A」は、アプリケーションコンポーネントBからの応答メッセージを受信する。

ここに示すように、これらの要素（アプリケーションコンポーネント、アプリケーションプロセス、アプリケーション関数および関係（トリガー、フロー））を組み合わせることで、非常に複雑な統合ケースをモデル化できます。UMLシーケンス図はソフトウェア設計における専門的な用途を持ちますが、ArchiMateは多くのモデル化目的に利用でき、アプリケーション設計にも適しています。

アプリケーション統合はエンタープライズアーキテクチャ（EA）における最も重要な要素の一つです。そのため、アプリケーションがデータをどのように交換するか、どのような相互作用メカニズムが使用されるかをより詳細にモデル化できることは有益です。統合パターンの深い理解に役立つ良いリソースは、『Enterprise Integration Patterns』という書籍です。ここにリンク.

追加された最終ユーザーのシーケンス（以下）は、ArchiMateの動的関係「トリガー」と「フロー」を使用するという同じ考え方に従っており、同期および非同期のメッセージングパターン（リクエスト-レスポンス、コールバック、およびパブリッシュ-サブスクライブなど）をモデル化するために使用できます。

シーケンスパターンビュー。

ETLプロセスビュー

ETLプロセスビュー。

EAI / ESBビュー

EAI – ESBパターンビュー。

レイヤードビュー

レイヤードビュー。

レイヤードビューは、対象領域の概要的なコンテキスト図として使用できます。このビューの主な利点は、アプリケーションがビジネスプロセスおよび提供するサービスにおいてどのように使用されているかを示すことです。上図ではArchiMateのGrouping要素を使用して異なるレイヤーをモデル化していますが、下図ではツールが提供する視覚的Group要素を使用しています（Archi).

ArchiMateでは、基本的に以下の3つのレイヤーがあります：1）ビジネスレイヤー、2）アプリケーションレイヤー、3）テクノロジーレイヤー。色は通常以下の通りです：ビジネスレイヤーは黄色、アプリケーションレイヤーはターコイズ、テクノロジーレイヤーは緑色（ArchiMateコアフレームワークを参照してください、リンク).

レイヤードビュー。

アプリケーションおよびデータベースビュー

データベースは、組織の全体的なエンタープライズアーキテクチャにおける意味のある単位です。たとえば「顧客データベース」や「製品データベース」などです。あるいは、アプリケーションのすべてのテーブル（例：「顧客テーブル」、「注文テーブル」、「請求書テーブル」など）を一つのデータベースとして構成することもできます。ArchiMate仕様によれば、データオブジェクトは論理データベースをモデル化するために使用できます（下図参照）。第9.4.1節「データオブジェクト」では、「データオブジェクトの典型的な例として、顧客レコード、顧客データベース、保険請求などがある」と述べています。「重要な例外として、データオブジェクトがデータの集合（たとえばデータベース）をモデル化する場合で、その中でインスタンスが一つしか存在しない場合があります」とも述べられています。ArchiMateには、特定の概念を異なる抽象レベル（および詳細度）で使用できる洗練された組み込みメカニズムがあります。したがって、たとえばデータオブジェクトは論理データベース、データベーステーブル、メッセージ構造（アプリケーション間で切り替わるもの）などをモデル化するために使用できます。

データベースモデル化に関する考慮事項。

アプリケーションコンポーネントとしてのデータベース。

データベースの抽象レベル。

データモデルビュー。

ユースケースビュー

ArchiMateは、アプリケーションの機能的視点からユースケースを分析するために使用できます。ユースケース（UMLで知られている）は、下図に示すように、アプリケーションサービスにマッピングできます。

ユースケースビュー（パターン1）。

ユースケースは、a) ビジネスユースケースと b) システムユースケース（別名：システムユースケース）に分けることができます。下図は、「主要なユースケース」をビジネスサービスとしてモデル化し、その後のシステムユースケースをアプリケーションサービスとしてモデル化する方法を示しています。

ユースケースビュー（例）。

ユースケースがアプリケーションサービスとして識別された場合、他の図（たとえばレイヤードビューなど）において、ターゲットアプリケーションの機能的要素としてさらに利用できます。言い換えれば、アプリケーションサービスはアプリケーションの振る舞い（機能性）を表します。ユースケース分析に関する詳細情報は、ArchiMate コックブックを参照してください。リンク.

テクノロジー視点

テクノロジーアーキテクチャレイヤービュー。

インフラストラクチャビュー

このビューはアプリケーションのプラットフォームを表します。このパターンは、実行環境の構成やビジネスアプリケーションのデプロイメントをモデル化するために使用できます。

インフラストラクチャビュー。

インフラストラクチャビュー（ネスト済み）。

実装および移行レイヤー／トランジションアーキテクチャレイヤービュー

実装ロードマップビュー

実装ロードマップビュー。

カバンボードビュー

カバンボード（EA）。

カバンボードは作業やワークフローを可視化するために使用できます。カバンボードは、開発要件、エピック、ユーザーストーリーなどがある程度バックログから「準備完了」状態（完了）へとどのように流れているかを示します。カバンボードは、開発案件の規模や範囲に応じてさまざまな用途に適用できます。たとえば、「エピック」はEAレベルで、「ユーザーストーリー」や「要件」はプロジェクトレベルで使用できます。作業アイテムの粒度は状況によって異なります。

汎用ビュー

汎用ビュー。

この簡略化されたビューは、特定のサービス、プログラム、またはプロジェクトのコンテキスト図として使用できます。

追加機能

コンテキスト概要 – ミルキーウェイ地図

これは、可能な限り同じビューで多くの情報を可視化するアプローチです。詳細については、ArchiMate用のミルキーウェイ地図を参照してください。リンク.

FM ミルキーウェイ地図（レベル2）。（注！このカラースキームはArchiMateのデフォルトカラーを使用しています。必要に応じて他の色を使用できます。）

協働ビュー

レイヤーは、以下のデータフロー図の例に示すように混在できます。

アプリケーション協働ビュー（拡張版）。

メタモデル

メタモデル。