ArchiMate の例
この記事では、ArchiMate 標準に従って階層化されたフレームワークに編成された ArchiMate サンプル ビューの豊富なコレクションを紹介します。これらの ArchiMate ビューは、ArchiMate 要素の使用方法を示しています。いくつかの例は、設計パターンとして使用できます。
例は、ArchiMate クックブックの例に基づいて、Visual Paradigm Onlineで設計されています。クックブックをまだチェックアウトしていない場合は、参照することをお勧めします。リンク: http://www.hosiaisluoma.fi/ArchiMate-Cookbook.pdf
ArchiMate サンプル ビュー
フレームワーク ビュー
このフレームワーク ビューは、使用されるすべてのビューを構造化します。ダイアグラム間のナビゲーションに使用できます。
モチベーションビュー
このモチベーション ビューを使用して、組織の設計または変革を推進する動機または原因、および企業内のすべての変更操作とビジネス変革の基盤となるエンタープライズ アーキテクチャを調べることができます。このビューは、規模と範囲が組織全体、組織のサブセット (たとえば、事業部門)、または特定のプログラムまたはプロジェクト (ソリューション レベル) を包含するかどうかにかかわらず、開発作業のビジョンを示します。結果 (またはその他の ArchiMate 要素) などの任意の ArchiMate 要素に値を追加して、実際の付加価値が何であるかを示すことができることに注意してください。
ビジネス動機モデル (BMM) [仕様 v.1.3、2015 年、OMG] は、動機要素を定義するために使用されます。
ミッション・バリュー・ビジョンビュー
組織の目的、ビジョン、および基本的な価値観はすべて、Mission-Values-Vision ビューを使用して表すことができます。組織の目的、組織が実際に行っていること、または行う予定の内容、およびその存在の主な理由を特定するのに役立ちます。ビジョンとは、将来における組織の望ましい状態です。組織のビジョン、文化、理想はすべて、コアバリューによって支えられています。組織のビジョンを実現するには、戦略的な目標を達成する必要があります。
参照: Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) ArchiMate によるモデリング戦略。
戦略的価値マップ ビュー
戦略的価値マップ ビューは、組織の戦略を視覚化します。すべての開発業務は、戦略的価値要素を含むこのビューから、直接的または間接的に引き出す必要があります。戦略的価値を視覚化することで、実際の戦略実行に関連する他のすべての側面を追跡することができます。アプローチは、この視点で表現し、伝え、現実に関連付けることができます。
利害関係者分析ビュー
利害関係者の分析ビューは、変更要因を特定する利害関係者の分析によく使用されます。最初に、重要な利害関係者を特定し、次に彼らにとって最善の変化の推進要因を特定します。「評価」の概念は、SWOT (強み、弱み、機会、脅威) 手法を使用するなど、ドライバーの詳細な分析に使用できます。通常どおり、さまざまな視点からさまざまな利害関係者ビュー図を作成できます。巨大なダイアグラムを小さなダイアグラムに分割するもう 1 つの理由は、わかりやすくするために、ダイアグラムをコンパクトにして読みやすくすることです。
利害関係者の見解
この利害関係者ビューは、利害関係者の動機を企業の目的に結び付けます。目標は、組織の発展の最も重要な要素です。すべての変更アクションの後続の要素は、これらの主な理由にまでさかのぼる必要があります。
原則ビュー
リスク & セキュリティ ビュー
リスクとセキュリティの概念は、このビューを通じて ArchiMate にマップされます。リスク管理には、セキュリティとデータ保護に関する懸念が含まれます。どちらもこのビューでカバーされます。
参考文献:
- ArchiMate® 言語を使用してエンタープライズ リスク管理とセキュリティをモデル化する方法、Open Group、DocumentNo: W172、2017。
- Modeling Enterprise Risk Management and Security with the ArchiMate® Language、オープン グループ、2015 年。
SWOT分析ビュー
目標ビュー
目標と主な結果
Objectives and Key Results の略である OKR は、目標を定義し、進捗状況を追跡するための一般的な管理方法です。これは、測定可能な目標に関する調整と関与の作成に役立ちます。OKR は、(1) 達成したい目標と、(2) その目標への進捗状況を追跡するために使用される主要な結果の 2 つの部分で構成されています。
目標は…
- 達成したいことの定性的な説明は記憶に残ります。短く、刺激的で、魅力的な目標が理想的です。チームは、目標によってやる気を起こさせ、挑戦する必要があります。
主な結果は…
- 目標達成に向けた進捗状況を追跡する一連の測定値。ターゲットごとに 2 ～ 5 個の主要な結果が必要です。重要な結果が多すぎると、覚えにくくなります。
以下に示すアクションを含む別のバージョン。
戦略ビュー
戦略ビュー
ArchiMate バージョン 3 では、「行動方針」、「能力」、「リソース」などのビジネス戦略関連の概念が利用可能になり、組織のビジネス プランのモデル化に使用できます。このビューの有用性と重要性は、組織の目標を戦略に結び付け、さらに機能を介してエンタープライズ アーキテクチャに結び付けられる方法にあります。このビューは、「目標ベースの戦略モデル」 (Azevedo et al. 2015) を適用するために使用できます。このモデルでは、目標が下位レベルの目標に分解できる階層を形成します。
ビジネス戦略ビュー
ビジネス動機モデル (BMM) ビュー
要件ビュー
この要件ビューは、戦略目標に基づいてニーズを収集するために使用できます。これは、戦略を実装に接続するプロセスです。戦略は実行まで追跡できます。
能力ビューへの戦略
下の ArchiMate の図に示すように、戦略から能力へのビューは、「ドライバー」や「目標」などの他の ArchiMate 要素とともに、能力ベースの計画 (CBP) に利用できます。このビューは、戦略の計画 (および実行) を支援するために使用できます。結果として、このタイプの視点は、IT4IT の「戦略からポートフォリオ」フェーズの一部である戦略から能力へのフェーズで採用できます。
機能マップ ビュー
Capability Map ビューを使用して、会社の能力 (何をするか、または何ができるか) の高レベルの概要を示すことができます。
能力計画ビュー
Capability Planning ビューは、Capability-Based Planning (CBP) で定義されているように、「戦略とエンタープライズ アーキテクチャの間のリンク」に利用できます。このアプローチを使用して、戦略を必要な機能にマッピングしたり、機能をリソースやその他の構成要素にマッピングしたりすることができます。
能力実現ビュー
能力実現ビュー 2
機能を実現するために使用できる要素を定義する方法を示す機能実現ビューの別の例。
バリュー ストリーム ビュー
バリュー チェーン/バリュー ストリームの開始時に、「有向関連付け」が使用されることに注意することが重要です。価値の「段階」は、価値の流れの中に見出すことができます。バリュー ストリームで構成される「バリュー チェーン」は、包括的な高レベルのバリュー ストリームに類似している可能性があります。IT4IT (リンク) は、次の 4 つのバリュー ストリームを含むバリュー チェーンを導入します: ポートフォリオへの戦略、展開への要件、履行への要求、および修正への検出 (リンク)。
バリュー ストリーム – 能力クロス マッピング ビュー
バリュー デリバリー チェーンの簡単な例を以下に示します。ArchiMate 3.1 エディションに搭載されている ArchiMate バリュー ストリーム要素を使用して、バリュー チェーン、バリュー ネットワーク、およびバリュー ストリームをモデル化できます。
これは、機能がバリュー ストリームをどのように支援 (提供) するかのより詳細な例です。この視点を使用して、会社が何を行っているか (ビジネス モデル) と機能が必要な理由、および価値創造との関係を定義できます。
Lean EA Framework (LEAF) のリファレンス実装には、このビュー (リンク) が含まれています。「バリュー ストリーム」、「バリュー デリバリー チェーン」の順に進みます。
ビジネスモデルキャンバスビュー
これは、A. Osterwalder のビジネス モデル キャンバス (BMC) の基本バージョンであり、ニーズに合わせて微調整できます。「サービス モデル キャンバス」や「リーン キャンバス」などのバージョン化された手法も利用できます。BMC は、たとえば、ビジネス モデルの設計と革新に使用できます。
ArchiMate で BMC をモデル化することにより、「ビジネス要求から設計仕様までの要件の追跡が容易になります」。これは、ビジネス モデルの変化が建築設計に与える影響を発見するのに役立ちます。」[LO Meertens と同僚]
総合的な開発には、戦略とビジネス モデルの分析のための組み込みのアーキテクチャ支援が含まれています。これにより、ビジネス アナリストと開発者は、ビジネス モデルが戦略をどの程度サポートし、組織内に適合しているか、またその逆も評価できます。
BMC がモデリング ツールでモデル化される場合、この方法の利点の 1 つは、BMC のすべての要素を同じモデル リポジトリの他のビューで再利用できることです。ビジネスモデルを転換すると、すべての変化はすぐに明らかになります。ビジネス モデラーは、サービスなどの新しい要素を構築したり、組織単位やリソースなど、リポジトリの既存の要素をすべて使用したりできます。
コンセプト キャンバス ビュー
上記のように、BMC にはさまざまな形式があります。ArchiMate のレイヤード アプローチは、このコンセプト キャンバスのレイアウトに反映されています。
ビジネス ビュー
ビジネス アーキテクチャ レイヤー ビュー。
ビジネス サービス マップ、プロセス マップなど、各レイヤーの EA ツール内で制御される要素のさまざまな「マップ」があります。マップを認識して導入したら、それらを他の図 (レイヤー ビューなど) で使用できます。マップの目標は、「EA アセット」カタログを「ポートフォリオ」(アイデア、サービス、プロジェクトなどのポートフォリオに類似) として扱うことです。プロパティや属性などの他の機能は、多くの場合、各要素の EA ツールによって提供されます。これらは、各側面の詳細を提供するために使用できます。このタイプの追加データは、さまざまなタイプの分析にも使用できます。
各レイヤーには、次のように複数のマップを含めることができます。
- ビジネス層のビジネス サービス、ビジネス アクター、およびビジネス プロセス。
- アプリケーション サービス、アプリケーション層のアプリケーション。
- テクノロジー層のテクノロジー サービス、プラットフォーム、およびテクノロジー。等々。
ビジネス レイヤ マップの例を次に示します。
ビジネス サービス マップ ビュー
ビジネス サービス マップ ビューは、会社のビジネス サービスの概要を提供します。管理目的で、このタイプのビューは「サービス カタログ」または「サービス ポートフォリオ」として利用できます。会社がクライアントに提供する商用サービスの種類を把握することは重要です。ビジネス サービスを使用して、基礎となる組織のプロセスと構造をすべてシミュレートすることもできます。その結果、ビジネス サービスは企業アーキテクチャの重要なコンポーネントとなっています。
ビジネス プロセス マップ ビュー
このビューは、組織のビジネス プロセスの概要を示す「プロセス マップ」として使用できます。
ビジネス プロセス連携ビュー
このビューは、たとえば、運用モデルをモデル化するために使用できます。
ビジネス アクター マップ ビュー
ビジネス アクションには、内部と外部の 2 種類があります。組織と協力する顧客、ビジネス パートナー、またはその他の利害関係者グループは、内部のビジネス アクターの例です。一方、外部のビジネス アクターは、企業と協力する顧客、ビジネス パートナー、またはその他の利害関係者グループ (公共部門の組織やその他のガバナンス機関など) です。 ）。
ビジネス アクターの協力ビュー
次に、2 つの使用シナリオを示します。
- 企業内ビュー: このビューは、内部のビジネス関係者がどのように協力して情報を共有するかを視覚化します。
- 企業間ビュー: 組織が機能する運用環境を表すエコシステム ビュー。エコシステムとは、相互作用を通じて協力する組織と商業パートナーの集まりです。サプライヤー、下請け業者、その他の企業間パートナー、および顧客がいます。
ビジネス プロセス ビュー
ビジネス プロセス ビューは、「ビジネス プロセス (または多数のプロセス) の高レベルの構造と構成、提供されるサービス、アクターの割り当てられた役割、およびビジネス プロセスによって使用される情報」を示します。このプロセス図には、プロセス フローの「分岐」と「結合」を表す「接合」要素が含まれています。
以下は、高度なプロセスの観点です。これが、上記のバリュー ストリーム ダイアグラムで示したビジネス モデルに基づいたオペレーティング モデルです。
SIPOC (サプライヤー、インプット、プロセス、アウトプット、顧客)
SIPOC (サプライヤー、インプット、プロセス、アウトプット、顧客) は、すべてのプロセスに類似した側面を定義するために使用できるシックス シグマ ツールです。これは、顧客がどのような価値を受け取り、どのように受け取るかというビジネス ケースを調べるための簡単な方法です。
プロセスの「スイムレーン」としてのビジネス ロールを使用したビジネス プロセス ビュー – レイヤード アプローチ
顧客は「ビジネス ロール A」で表され、カスタマー ジャーニー パスは最上部の「スイムライン」で表されます。
ビジネス ロール (「スイムレーン」として視覚化) はプロセス ステップ (アクティビティ) 内にネストされていることに注意してください。これは、これらのビジネス ロールがこれらのビジネス プロセス/プロセス ステージに割り当てられていることを意味します。結果として、このビューは階層化されたビューとビジネス プロセス ビューのハイブリッドです。
このバージョンでは、情報とデータの流れが示されています (フロー関係)。クライアントの移動経路は、上部の「スイムライン」（引き金となる関係に関連する活動）によって表されます。
サービス設計の方法論を以下に示します。カスタマー ジャーニー パス (役割 A) は、ビジネス サービス (1 および 2) を介して組織 (役割 B および C) に関連付けられている最上部の「スイムライン」によって表されます。
階層化されたビジネス プロセス ビュー
このビューを使用して、手動と自動の両方の手順でビジネス プロセスを表すことができます。
カスタマージャーニーマップビュー
クライアントジャーニーを高レベルで調査する必要がある場合、このバージョンは動機要素と戦略要素を利用して生成されます。
顧客サービス パスをさらに詳細に調べる必要がある場合、このバージョンは、ビジネスおよびアプリケーション レイヤー (コア) パーツを使用して生成されます。
顧客体験は、この顧客中心の視点の焦点です。この「サービスデザイン」関連の手法は、作成中のサービスの「アウトサイドイン」開発に焦点を当てています。これは、顧客に、そして間接的に組織に価値を提供する上でのサービスと製品の重要性を強調しています。カスタマー ジャーニー ルートを使用して、多くのアプリケーション サービスとアプリを含む顧客バリュー ストリームを視覚化できます。
サービス ブループリント ビュー
このサービス ブループリント ビューは、顧客とサービスを中心にしていますが、サービスの「インサイド アウト」の側面も強調しています。サービス駆動型の開発戦略では、この手法を使用して構築されるサービスの基本的な動作および構造上の影響を特定できます。その結果、このビューは、顧客体験主導のアプローチにプロセスと機能の要因を追加します。
このビューは、さまざまな形で見つけることができます。レイヤーと要素の間の情報の流れがこの例の主題です。
ユーザー ストーリー ビュー
このビューを使用して、ユーザー ストーリーを視覚化できます。
クラウド サービス モデル ビュー
インフォメーションビュー
情報のモデル化には、次の抽象化レベルを使用できます。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) を介して提供される動作機能は、アプリケーション サービス (上図) と呼ばれます。「同じコインの異なる側面」は、アプリケーション サービスとアプリケーション インターフェイスです。
アプリケーション アーキテクチャ ビュー
同じビューにアプリケーションとアプリケーション モジュールの両方があるため、このビューは EA とソリューション レベルの手法を組み合わせたものです。
アプリケーション コンポーネント モデル (CM)
アプリケーション コンポーネント モデル 0-n は、さまざまな抽象化レベルの次の図で構成されるアプリケーション アーキテクチャをモデル化する手法です。
- CM-0 レベルの図は、アプリケーションが他のアプリやユーザーと対話する方法など、アプリケーションがその環境と対話する方法を示しています。ターゲット アプリケーションを表すためにブラック ボックスが使用されます。
- ターゲット アプリケーションは、モジュール (主要なコンポーネント) と、それらのモジュールが CM-1 レベルで提供および要求するアプリケーション サービス (またはアプリケーション インターフェイス) に分割されます。ホワイトボックスは、ターゲット アプリケーションを表すために使用されます。
- モジュールは、CM-2 レベルでサブコンポーネントに分割されます。（必須段数は状況により異なります。）
アプリケーション コンポーネントとアプリケーション サービスは、以下のアプリケーション コンポーネント モデル (CM) の図に示されています。状況によっては、アプリケーション サービスの代わりにアプリケーション インターフェイスを使用できます。いつものように、当面のタスクに適したモデリング スタイルを使用し、十分に有益で付加価値のある側面だけをモデル化することが重要です。機能的な機能を強調するか、より詳細にモデル化するか (たとえば、正確な命名法を使用して実際のインターフェイスをモデル化するか) は、モデラーに任されています。
アプリケーション コンポーネントとアプリケーション サービスは、以下のコンポーネント モデル図に示されています。アプリケーション サービスを使用する代わりに、アプリケーション インターフェイスを使用することもできます。
アプリケーション コンポーネント モデル – 0 (CM-0)
ターゲット アプリケーションと周囲のアプリ間の相互作用は、Component Model – 0 (CM-0) レベル (上記) で表されます。必要なすべてのアプリケーション サービス (またはアプリケーション インターフェイス) について説明します。エンタープライズ アーキテクチャ レベルのコンポーネントとそのサービスは、図の 0 レベルで表され、ターゲット アプリケーションは中央にあります。
アプリケーション コンポーネント モデル – 1 (CM-1)
コンポーネント モデル – 1 (CM-1) レベル (上記) は、ターゲット アプリケーションがどのようにモジュール (またはプライマリ コンポーネント) に分割されているか、およびどのモジュールがどのアプリケーション サービス (またはアプリケーション インターフェイス) を担当しているかを示します。ノート！外部アプリはこのレベルで表示する必要はありませんが、そのサービス (またはインターフェイス) は表示されます。より多くの低レベルの部分が表示される場合、より多くの高レベルの要素を省略できます/省略しなければなりません – わかりやすくするため: ダイアグラムを理解しやすく保つため.
アプリケーション コンポーネント モデル – 2 (CM-2)
コンポーネント モデル – 2 (CM-2) レベル (上図) は、ターゲット アプリケーションのモジュールがサブコンポーネントで構成され、相互作用する方法を示しています。
アプリケーション機能ビュー
アプリケーション機能の分解: システムの機能とは何か、システムはどのようなアプリケーション サービスを提供するのか?
申請プロセス ビュー
以下は、アプリケーション プロセス ビューのネスト ビューです。
申請プロセス ビューの内部コンテンツを次に示します。
アプリケーション コンポーネント シーケンス図ビュー
シーケンス図は、ArchiMate で正確にカバーされているわけではありません。代わりに、UML でカバーされています。ただし、以下に示すように、ArchiMate を使用して、アプリケーション コンポーネントによって実行される一連の操作をモデル化できます。
アプリケーション コンポーネント間のダイナミクスをモデリングするには、動的リレーション「トリガー」と「フロー」を使用できます。このビューのレイアウトは、UML シーケンス図のレイアウトに似ています。
アプリケーション コンポーネント シーケンス図ビュー 2
このバージョン (下の図) は、ArchiMate を使用して、アプリケーション コンポーネントの内部要素が実行するアクションをモデル化する方法を示しています。行動プロセスまたは機能、および構造サブコンポーネントは、内部部品の例です。Application Process-、Application Function-、および Application Component-要素は、それらをモデル化するために使用されます。これらは代替手段としてのみ提供されています。
このシーケンス図 (上記) のアクションは次のとおりです。
- アプリケーション コンポーネント「A」のサブプロセス「X」は、パラメータ「A」を使用して要求メッセージをアプリケーション B に送信します。
- アプリケーション コンポーネント「B」のサブプロセス「B-1」は着信要求を取得し、(同期的に) アプリケーション コンポーネント C を呼び出します。アプリケーション関数「Y」は要求を受け入れ、特定のアクションを実行して戻ります。
- アプリケーション コンポーネント「B」のもう一方のサブプロセス「B-2」は、パラメーターを含むメッセージをアプリケーション コンポーネント D に送信し、確認応答を受信します。アプリケーション コンポーネント「D」のサブコンポーネント「D」が処理を行います。
- アプリケーション コンポーネント B からの応答メッセージは、アプリケーション コンポーネント「A」によって受信されます。ここに示すように、これらの要素 (アプリケーション コンポーネント、アプリケーション プロセス、アプリケーション機能) および関係 (トリガー、フロー) の組み合わせにより、非常に複雑な統合ケースをモデル化できます。 UMLシーケンス図はソフトウェア設計に特化した目的を持っていますが、ArchiMate は非常に多くのモデリング目的で利用でき、アプリケーション設計でも利用できます。
エンタープライズ アーキテクチャの最も重要な側面の 1 つは、アプリケーション統合 (EA) です。そのため、アプリケーションがどのようにデータを切り替え、どのような対話方法が採用されているかをより詳細に説明できると便利です。統合パターンについて学び始めるのに最適な書籍「Enterprise Integration Patterns」へのリンクを次に示します。
同期および非同期メッセージング パターンの両方をモデル化するために使用できる ArchiMate の動的リレーションシップ トリガーとフローを活用するという同じ考え方が、エンド ユーザーが含まれるシーケンスで利用されます (下の図) (要求-応答とコールバック、また公開-購読など）。
ETL プロセス ビュー
EAI/ESB ビュー
階層化されたビュー
レイヤー ビューは、ターゲット エリアの概要コンテキスト ダイアグラムとして使用できます。このアプローチの主な利点は、アプリケーションがビジネス プロセスでどのように使用され、どのようなサービスが提供されるかを示すことです。さまざまなレイヤーをモデル化するために、上の図では ArchiMate グループ要素を使用していますが、下の図ではツールの視覚的なグループ要素を使用しています。
ArchiMate には次の 3 つのレイヤーがあります。3 つのレイヤーとは、1) ビジネス レイヤー、2) アプリケーション レイヤー、3) テクノロジ レイヤーです。通常、これらは次のように色分けされています。ビジネス レイヤーは黄色、アプリケーション レイヤーは青緑色、テクノロジー レイヤーは緑色です。
アプリケーション & データベース ビュー
データベースは、組織の全体的な企業アーキテクチャの重要なコンポーネントです。たとえば、「顧客データベース」、「顧客データベース」、「製品データベース」などです。あるいは、データベースは、アプリケーションのすべてのテーブル (たとえば、「Customer テーブル」、「Orders テーブル」、「Invoices テーブル」など) の論理的 (および物理的) なコンパイルであり、集合的にデータベースを形成します。ArchiMate 標準に従って、データ オブジェクトを使用して論理データベースをモデル化できます (下図)。第 9.4.1 章「データ オブジェクト」には次のように記載されています。「重要な例外は、データ オブジェクトを使用して、データベースなどのインスタンスが 1 つしかないデータ コレクションをモデル化する場合です。ArchiMate には、同じ概念をいくつかの抽象化レベル (および詳細レベル) に適用できる巧妙な組み込みシステムが含まれています。その結果、たとえば、データ オブジェクトを使用して、論理データベース、データベース テーブル、メッセージ構造 (アプリ間で切り替え) などをシミュレートできます。
アプリケーション コンポーネントとしてのデータベース
データベースの抽象化レベル:
データ モデル ビュー:
ユースケース ビュー
ArchiMate を使用して、アプリケーションの機能的な観点からユース ケースを調べることができます。下の図に示すように、ユース ケース (UML で定義) はアプリケーション サービスにマッピングできます。
ユース ケースは、ビジネス ユース ケースとシステム ユース ケース (システム ケース) の 2 つのカテゴリに分類できます。次の図は、「主要なユース ケース」がビジネス サービスによってどのように表され、その後のシステム ケースがアプリケーション サービスによって表されるかを示しています。
ユース ケースをアプリケーション サービスとして定義すると、他の図 (レイヤー ビューなど) でターゲット アプリケーション機能の一部として使用できます。つまり、アプリケーション サービスは、アプリケーションの動作 (機能) を表します。ユース ケース分析の詳細については、ArchiMate クックブックのリンクを参照してください。
テクノロジー ビュー
テクノロジー アーキテクチャ レイヤー ビュー。
インフラストラクチャ ビュー
このビューは、アプリケーションのプラットフォームを示しています。このパターンは、ランタイム環境のセットアップとビジネス アプリケーションの展開をモデル化するために使用できます。
インフラストラクチャ ビュー (ネスト):
実装および移行レイヤー / 変換アーキテクチャ レイヤー ビュー
実装ロードマップ ビュー
かんばんビュー
かんばんボードは、作業とプロセスを視覚化するためのツールです。かんばんボードは、開発ニーズ、エピック、ユーザー ストーリー、およびその他の項目がバックログから準備完了 (完了) にどのように流れるかを示しています。開発シナリオの量と幅に応じて、カンバン ボードはさまざまな目的に使用できます。たとえば、「エピック」は EA レベルで使用でき、「ユーザー ストーリー」または「要件」はプロジェクト レベルで作業項目として使用できます。状況に応じて、タスク アイテムの粒度が異なる場合があります。
汎用ビュー
この単純化された表現は、たとえば、特定のサービス、プログラム、またはプロジェクトのコンテキスト図として使用できます。
エクストラ
コンテキストの概要 – 天の川マップ
これは、一度の見た目で可能な限り視覚化するためのテクニックです。詳細については、ArchiMate を使用した天の川マップを参照してください。
協力ビュー
以下のデータ フロー ダイアグラムの例に示すように、レイヤーを混在させることができます。
メタモデル
これらの例は、 Visual Paradigm Onlineで作成されています。
