Visual Paradigm Enterprise Architect を使用した ArchiMate 4 ガイド

このガイドでは、Visual Paradigm Enterprise Architect を使用して ArchiMate 4 モデルを作成、整理、検証、維持、公開する方法を説明します。これは、ArchiMate 3.2 から ArchiMate 4 へ移行するエンタープライズアーキテクト、ソリューションアーキテクト、ビジネスアナリスト、およびアーキテクチャチームを対象としています。

Visual Paradigm 18.0 以降では、専用の ArchiMate 4 エディタ、ArchiMate 4 パレット、ネイティブな関係性の多重度、ドキュメントサポート、XML 入力/出力、共同作業機能、および ArchiMate 3.2 ダイアグラムとの下位互換性が提供されます。

メニュー名は Visual Paradigm のリリースやエディションによってわずかに異なる場合があります。以下の手順は、Visual Paradigm Desktop Enterprise Edition 18.0 以降を前提としています。

1. ArchiMate の用途

ArchiMate は、以下を記述するために使用されるエンタープライズアーキテクチャモデリング言語です:

ビジネス戦略と目標
組織構造
製品とサービス
ビジネスプロセスと能力
アプリケーションとアプリケーションサービス
データと情報
技術インフラストラクチャ
プロジェクト、作業パッケージ、段階、および実装ロードマップ
アーキテクチャドメイン間の関係

ArchiMate はプロジェクト管理手法ではなく、BPMN、UML、またはデータモデリングを置き換えるものではありません。代わりに、それらのモデルを接続する統合されたアーキテクチャビューを提供します。

例えば:

ArchiMate の価値は、各ドメインを孤立してモデル化するのではなく、これらの概念間の関係を示すことによってもたらされます。

2. ArchiMate 4 の概念的変更

ArchiMate 4 は、よりドメイン指向の構造を導入し、専門的かつ重複した要素の数を削減します。

2.1 レイヤーからドメインへ

ArchiMate 3.2 では一般的に、レイヤー指向のビューが使用されていました:

戦略
ビジネス
アプリケーション
技術
実装と移行
動機

ArchiMate 4 は、言語をドメインを中心に整理します:

共通
ビジネス
アプリケーション
テクノロジー
動機
戦略
実装と移行

共通ドメインには、さまざまなドメインで適用可能な再利用可能な概念が含まれています。動機ドメインはArchiMate 4フレームワークの中央に位置し、アーキテクチャ上の意思決定は目標、駆動力、および成果と結びつくべきであることを強調しています。

2.2 ArchiMate 六角形モデル

ArchiMate 4フレームワークは一般的にArchiMate六角形モデルとして描かれます。これは以下の間の関係を強調しています：

動機
戦略
コアアーキテクチャ
実装と移行

六角形モデルは概念図として使用し、必ずしもすべての図のレイアウトとして使用する必要はありません。詳細なアーキテクチャ図は通常、1 つの利害関係者の関心と1 つの特定の視点に焦点を当てるべきです。

2.3 統一された概念

ArchiMate 4は、ビジネス、アプリケーション、およびテクノロジーの概念間の重複を削減します。各レイヤーに対して類似の行動概念の別バージョンを作成するのではなく、この言語は文脈に応じて解釈可能な再利用可能な概念を重視します。

これは、要素を選択する際には、単にそれらが存在するドメインではなく、そのアーキテクチャ上の意味に基づいて行うべきであることを意味します。

2.4 関係における多重度

ArchiMate 4は、関係における多重度をサポートします。例は以下の通りです：

1
0..1
1..*
0..*

例：

顧客 ── 利用 ── 0..* カスタマーサービス

これにより、モデルは接続子上に直接基数とアーキテクチャ上の制約を表現できます。Visual Paradigmは、ArchiMate 4の関係における多重度の表示をサポートしています。

2.5 廃止または統合された概念

ArchiMate 3.2からのいくつかの概念は削除され、統合され、またはより一般的な要素を使用して表現されました。ArchiMate 4のガイダンスで報告されている例には以下が含まれます：

コア関係セットから構成が削除されました
専門的な相互作用概念が統合されました
契約、制約、ギャップ、および表現はもはや別々の概念として扱われない
パスが共通ドメインに移行された

既存モデルを移行する際、単に古い要素の名前を変更するだけではいけません。まず、元のモデル要素の意味を特定し、その後、適切な ArchiMate 4 の概念を使用してその意味を表現してください。

3. Visual Paradigm のインストールと準備

3.1 必要なエディション

エンタープライズアーキテクチャと ArchiMate サポートを含む Visual Paradigm エディションを使用してください。エンタープライズエディションは、以下の要件を持つ組織に適しています：

ArchiMate モデリング
チームコラボレーション
モデル検証
ドキュメント生成
プロジェクト公開
XML のインポートとエクスポート
BPMN、UML、およびその他のモデルタイプとの統合

Visual Paradigm の ArchiMate 機能には、ドラッグ＆ドロップ編集、再利用可能なモデル要素、カスタムビューポイント、コラボレーション、オンライン図の表示、および BPMN および UML モデルへのリンクが含まれています。

3.2 プロジェクトの作成

Visual Paradigm を起動します。
選択してください：プロジェクト > 新規プロジェクト.
プロジェクト名を入力してください。例：
```
カスタマーサービス変革
```
プロジェクトの場所を選択してください。
プロジェクトを保存してください。
図を追加する前に、論理的なパッケージ構造を作成してください。

有用なパッケージ構造の例は次の通りです：

カスタマーサービス変革
├── 00 ガバナンス
├── 01 動機
├── 02 戦略
├── 03 ビジネス
├── 04 アプリケーション
├── 05 テクノロジー
├── 06 実装と移行
├── 07 ビューポイント
├── 08 カタログ
└── 09 レポート

3.3 ArchiMate 4 エディタの有効化

ArchiMate 4 図を作成するには：

選択してください：図 > 新規.
検索：ArchiMate.
ArchiMate 3.2 と ArchiMate 4 のオプションが別々に表示されている場合は、ArchiMate 4 ダイアグラムエディタを選択してください。
ダイアグラムまたは視点テンプレートを選択してください。
ダイアグラムを適切なパッケージに配置してください。

以下のような説明的な名前を付けてください：

カスタマーサービス – モチベーションビュー

Visual Paradigm 18.0 では、ArchiMate 3.2 ダイアグラムを扱う能力を維持したまま、新しい ArchiMate 4 ダイアグラムエディタとパレットが導入されました。既存の 3.2 モデルをすぐに移行する必要はありません。

4. アーキテクチャリポジトリの整理

リポジトリは、再利用可能なモデル要素と利害関係者向けのビューを区別する必要があります。

4.1 再利用可能な要素

可能な限り、各重要なアーキテクチャ要素を一度だけ作成してください：

1 つの標準的な顧客エンティティ
1 つの標準的なカスタマーサービス
1 つの標準的な CRM アプリケーション
1 つの標準的な顧客管理機能
1 つの標準的な CRM データベース

それらの要素を再描画するのではなく、複数のダイアグラムで再利用してください。

Visual Paradigm はダイアグラム間での要素の再利用をサポートしており、基盤となる要素への変更は他のダイアグラムにも反映されます。

4.2 ビュー

ビューは、特定の利害関係者の関心のために作成されたダイアグラムです。例は以下の通りです：

経営層のモチベーションビュー
機能マップ
ビジネスサービスビュー
アプリケーション連携ビュー
技術インフラビュー
実装ロードマップ
移行影響ビュー

企業全体を含む巨大な図を1つ作成しないでください。大きな図は読み取り、検証、維持が困難です。

4.3 命名規則

安定した名称を使用し、要素名に一時的なプロジェクト情報を埋め込まないようにしてください。

推奨:

顧客管理機能

ではなく:

新しいCRM機能 – プロジェクト・フェニックス

プロジェクト固有の情報には、メモ、プロパティ、またはタグ付き値を使用してください。

実用的な命名パターンは次の通りです:

<要素タイプ>: <ビジネス意味>

例:

機能: 顧客管理
ビジネスプロセス: 顧客リクエストの解決
アプリケーションコンポーネント: CRMプラットフォーム
テクノロジーサービス: 身元認証
作業パッケージ: CRMプラットフォームの展開

5. ArchiMate 4 ドメインと典型的な要素

以下の表は、各ドメインの主なモデリング目的を要約しています。

ドメイン	目的	典型的な例
動機	変更が必要な理由	利害関係者、ドライバー、評価、目標、要件、原則
戦略	方向性と意図されたビジネス成果	機能、リソース、行動方針、価値連鎖
ビジネス	組織とビジネス行動	ビジネスアクター、役割、コラボレーション、プロセス、機能、サービス、製品、ビジネスオブジェクト
アプリケーション	ソフトウェアの動作と構造	アプリケーションコンポーネント、アプリケーションコラボレーション、アプリケーション機能、アプリケーションサービス、データオブジェクト
テクノロジー	IT と物理技術	ノード、デバイス、システムソフトウェア、技術コラボレーション、技術機能、技術サービス
共通	再利用可能なドメイン横断概念	共通サービス、プロセス、機能、イベント、パス、および関連する一般的な概念
実装と移行	変更の実行と移行	作業パッケージ、デリバブル、プラトー、ギャップ、実装イベント、移行ロードマップ

正確な要素名と利用可能性は、インストールされた Visual Paradigm バージョンの ArchiMate 4 パレットと照合して確認する必要があります。

6. 最初の ArchiMate 4 モデルの構築

以下の例を使用してください：

ある企業は、統一された CRM プラットフォームの導入により顧客サポートを改善したいと考えています。この変更は、応答時間の短縮、顧客の可視性の向上、および顧客サービスチャネルの統合をもたらす必要があります。

ステップ 1：動機のモデル化

次の名前の図を作成してください：

カスタマーサービス – 動機ビュー

追加：

ステークホルダー：顧客
ステークホルダー：カスタマーサービスマネージャー
ドライバー：顧客体験の悪さ
評価：断片的な顧客情報
目標：顧客満足度の向上
目標：サービス応答時間の短縮
要件：統一された顧客情報
原則：顧客データはアクセス可能でなければならない

要素を次のような関係で接続してください：

顧客体験の悪さ
    影響する
顧客満足度の向上

断片的な顧客情報
    影響する
統一された顧客情報

統一された顧客情報
    支援する
顧客満足度の向上

簡略化されたビューは次のようになります：

[カスタマーサービスマネージャー]
            |
         価値がある
            v
[顧客満足度の向上]
            ^
         支援する
            |
[統一された顧客情報]
            ^
         対処する
            |
[断片的な顧客情報]

この図はビジネスステークホルダーにとって理解しやすいように保ってください。この段階ではアプリケーションやインフラストラクチャを追加しないでください。

ステップ 2：戦略的方向性のモデル化

作成:

カスタマーサービス – 戦略ビュー

追加:

能力: 顧客管理
能力: オムニチャネルサポート
行動方針: 統合CRMの導入
バリューストリーム: 顧客問題の解決
リソース: 顧客情報

要素を接続する:

統合CRMの導入
    を可能にする
顧客管理

統合CRMの導入
    を可能にする
オムニチャネルサポート

顧客管理
    を支援する
顧客問題の解決

この図は以下の問いに答えます:

必要な能力は何ですか？
それらを創出する戦略的イニシアチブは何ですか？
どのバリューストリームが改善されますか？
どのリソースが重要ですか？

ステップ3: ビジネスアーキテクチャをモデル化する

作成:

カスタマーサービス – ビジネスアーキテクチャビュー

追加:

ビジネスアクター: 顧客
ビジネスロール: カスタマーサービス担当者
ビジネスコラボレーション: カスタマーサービスチーム
ビジネスプロセス: 顧客問題の登録
ビジネスプロセス: 顧客問題の分析
ビジネスプロセス: 顧客問題の解決
ビジネスサービス: カスタマーサポートサービス
ビジネスオブジェクト: 顧客ケース
ビジネスオブジェクト: 顧客プロファイル

典型的なフローは以下の通りです:

顧客
   |
 要求
   v
カスタマーサポートサービス
   |
 提供
   v
カスタマーサービスチーム
   |
 実行
   v
顧客問題の登録
   |
 参照
   v
顧客ケース

アーキテクチャレベルでプロセスシーケンスを ArchiMate ダイアグラムにモデル化してください。詳細なワークフローロジックが必要な場合は、ビジネスプロセスを BPMN モデルにリンクまたはトレーシングしてください。

ステップ 4：アプリケーションアーキテクチャをモデル化する

作成：

カスタマーサービス – アプリケーションビュー

追加：

アプリケーションコンポーネント：CRM プラットフォーム
アプリケーションコンポーネント：コンタクトセンタープラットフォーム
アプリケーションコンポーネント：カスタマーポータル
アプリケーションコンポーネント：レポートプラットフォーム
アプリケーションサービス：カスタマーケース管理サービス
アプリケーションサービス：カスタマープロフィールサービス
データオブジェクト：カスタマーケースデータ
データオブジェクト：カスタマープロフィールデータ

モデルを接続する：

CRM プラットフォーム
    提供
カスタマーケース管理サービス

カスタマーケース管理サービス
    提供
カスタマーサービスチーム

CRM プラットフォーム
    アクセス
カスタマーケースデータ

カスタマーポータル
    アクセス
カスタマープロフィールサービス

コンタクトセンタープラットフォーム
    使用
カスタマーケース管理サービス

複数のアプリケーションが連携してサービスを提供する場合は、アプリケーションコラボレーションを使用してください。

ステップ 5：テクノロジーアーキテクチャをモデル化する

作成：

カスタマーサービス – テクノロジービュー

追加：

ノード：クラウドアプリケーションプラットフォーム
ノード：統合プラットフォーム
ノード：ID プラットフォーム
システムソフトウェア：リレーショナルデータベース管理システム
テクノロジーサービス：認証サービス
テクノロジーサービス：統合サービス
デバイス：エージェントワークステーション

要素を接続する：

クラウドアプリケーションプラットフォーム
    実現
CRM プラットフォーム

統合プラットフォーム
    提供
統合サービス

ID プラットフォーム
    提供
認証サービス

CRM プラットフォーム
    使用
認証サービス

CRM プラットフォーム
    アクセス
リレーショナルデータベース管理システム

テクノロジービューは、アプリケーションアーキテクチャがどのようにホストされ、サポートされているかを説明するべきです。図が技術的な運用に特意に意図されていない限り、すべてのサーバー、ポート、ライブラリ、またはデプロイメントパラメータをリストアップしないでください。

ステップ 6：モデルの実装と移行

作成：

カスタマーサービス – 実装ロードマップ

追加：

作業パッケージ：CRM プラットフォームの設定
作業パッケージ：コンタクトセンターの統合
作業パッケージ：顧客データの移行
作業パッケージ：サービス担当者の研修
納品物：設定済みの CRM プラットフォーム
プラトー：現状
プラトー：移行状態
プラトー：目標状態
実装イベント：CRM 本番稼働
ギャップ：断片化された顧客情報

以下のような依存関係を作成する：

CRM プラットフォームの設定
    トリガー
コンタクトセンターの統合

コンタクトセンターの統合
    トリガー
顧客データの移行

顧客データの移行
    トリガー
CRM 本番稼働

現状
    移行先
移行状態

移行状態
    移行先
目標状態

順序とアーキテクチャの変更を示すために、ロードマップまたは移行ビューを使用してください。詳細なスケジュールは通常、プロジェクト管理ツールに残す必要があります。

7. Visual Paradigm でのビューポイントの作成

ビューポイントは、モデルを特定の利害関係者または関心に関連する概念に限定します。

7.1 事前定義されたビューポイントの使用

図を作成する場合：

選択 図 > 新規.
ArchiMate 4 の図またはビューポイントを選択してください。
適切なテンプレートを選択してください。例：
- 動機付けビュー
- 戦略ビュー
- ビジネスアーキテクチャビュー
- アプリケーション協力ビュー
- 技術ビュー
- 実装および移行ビュー
そのビューポイントに関連する要素のみを追加してください。
必要に応じて、無関係な関係は非表示にしてください。

Visual Paradigmは、特定のアーキテクチャ上の関心に図を集中させるための事前定義済みおよびカスタムビューポイントをサポートしています。

7.2 カスタムビューポイントの作成

標準的なビューポイントが組織のコミュニケーションニーズを満たさない場合に、カスタムビューポイントを作成してください。

例えば、「データコンプライアンスビュー」には以下が含まれる場合があります：

ビジネスオブジェクト
データオブジェクト
アプリケーションコンポーネント
要件
原則
技術サービス
アクセス関係
実現関係

カスタムビューポイントは以下を指定する必要があります：

対象読者
アーキテクチャ上の関心
許可された要素タイプ
許可された関係タイプ
必須のメタデータ
命名および色の規約

7.3 ビューポイント設計ルール

優れたビューポイントは以下の条件を満たすべきです：

特定のアーキテクチャ上の質問に答える
限られた数の要素タイプを使用する
一つの主要な対象読者を持つ
無関係な詳細を避ける
一貫したレイアウトを使用する
明確なタイトルと凡例を含めること

例：

注文から入金までのプロセスをサポートするアプリケーションはどれか？
変革によって影響を受ける機能はどれか？
規制対象の顧客データはどこに保存されているか？
目標状態に到達するために必要な変更は何か？

8. ArchiMate 4 における関係

関係は慎重に使用すること。関係は要素そのものよりも多くの意味を伝えることが多い。

8.1 一般的な関係の種類

関係	使用するタイミング
関連	一般的な、特定されていない接続が存在する
サービス提供	ある要素が別の要素にサービスまたは機能を提供する
アクセス	ある要素がオブジェクトを読み取り、書き込み、またはその他の方法でアクセスする
割り当て	振る舞いがアクティブな構造に割り当てられる
実現	ある要素が別の要素を実現または実装する
影響	ある要素が別の要素の動機または結果に影響を与える
トリガー	ある振る舞いまたはイベントが別の振る舞いまたはイベントを開始する
フロー	情報、価値、または物質が要素間を流れる
集約	全体が関連する部分を含み、強い所有関係はない
構成	使用する前に ArchiMate 4 のメタモデルを確認すること；3.2 のように利用できない場合がある
特殊化	ある要素は別の要素の特殊化された形態である
結合点	関係の結合または分離

8.2 サービングと実現の選択

使用 サービング 1 つの要素が別の要素に機能を提供する場合:

CRM アプリケーション
    サービング
カスタマーサービスチーム

使用実現 1 つの要素が別の要素を実装または具現化する場合:

CRM プラットフォーム
    実現
顧客ケース管理サービス

単に 2 つの要素が関連しているからといって、実現を使用しないでください。

8.3 多重性のモデリング

関係コネクタを選択し、その仕様またはプロパティを開きます。Visual Paradigm のバージョンがこれらのフィールドを公開している場合は、ソースとターゲットの多重性を入力してください。

例:

顧客 1 ── 保有 ── 0..* 顧客ケース
カスタマーサービス担当者 1..* ── 実行 ── カスタマーサービスプロセス
アプリケーションコンポーネント 1 ── 実現 ── 1..* アプリケーションサービス

多重性は、意味のあるアーキテクチャルールを表す場合のみ使用してください。すべてのコネクタに任意の基数を追加しないでください。

9. プロパティ、タグ付き値、およびメタデータの活用

成熟したアーキテクチャリポジトリには、名前と関係以上の情報が必要です。

有用なプロパティには以下が含まれます:

所有者
ライフサイクルステータス
ビジネスの重要度
データ分類
アプリケーションの健全性
技術の健全性
目標状態
現状
計画された廃止日
規制対象範囲
コストセンター
ロードマップフェーズ
リスク評価

アプリケーションコンポーネントのメタデータの例:

名称: CRM プラットフォーム
所有者: カスタマーオペレーション
ライフサイクル: 目標
重要度: 高
データ分類: 機密
ロードマップフェーズ: フェーズ 2
技術健全性: 良好
ビジネス適合性: 中

リポジトリ全体でカスタムプロパティまたはタグ付き値を一貫して使用してください。Visual Paradigm では、プロジェクト固有の情報用にユーザー定義プロパティと ETL ベースのモデルカスタマイズがサポートされています。

10. 色と視覚的慣習

色は図を装飾するためではなく、制御された意味を伝えるために使用すべきです。

色のパレットの例:

色	意味
青	既存/現状の要素
緑	目標状態の要素
オレンジ	計画された変更
赤	リスク、ギャップ、または課題
グレー	外部または文脈的な要素
パープル	共有プラットフォームまたは共通機能

色を使用するすべての図に対して凡例を作成してください。ある図で色がライフサイクルステータスを、別の図でドメインタイプを表す場合、その区別を明確に文書化してください。

Visual Paradigm では、ArchiMate 図に対して書式設定オプションと色の凡例が提供されます。

11. ArchiMate を BPMN、UML、およびデータモデルに連携させる

ArchiMate は、より詳細なモデルの上に位置するアーキテクチャ層として機能すべきです。

11.1 ArchiMate と BPMN

ArchiMate を使用してモデル化:

ビジネス機能
高レベルのビジネスプロセス
ビジネスサービス
アプリケーションサポート

BPMN を使用してモデリングする:

詳細なプロセスフロー
イベント
ゲートウェイ
人的タスク
メッセージフロー
例外処理

トレーサビリティの例:

ArchiMate ビジネスプロセス:
顧客問題の解決

リンク先

BPMN プロセス:
顧客問題解決ワークフロー

11.2 ArchiMate と UML

ArchiMate を使用して表示する:

アプリケーションコンポーネント
アプリケーションサービス
アプリケーションコラボレーション
データオブジェクト

UML を使用して表示する:

クラス構造
コンポーネントインターフェース
シーケンスの動作
デプロイメントの詳細
API デザイン

11.3 ArchiMate とデータモデリング

アーキテクチャレベルの情報概念には ArchiMate データオブジェクトを使用します。必要に応じて、詳細なエンティティ関係モデルまたは論理データモデルにリンクします。

例:

ArchiMate データオブジェクト:
顧客プロファイルデータ

リンク先

論理データモデル:
顧客、顧客住所、顧客連絡先設定

Visual Paradigm は複数のモデリング言語をサポートしており、トレーサビリティのために ArchiMate ダイアグラムを BPMN および UML モデルにリンクすることができます。

12. モデル検証

検証はプロジェクトの終了時だけでなく、継続的に行うべきです。

12.1 基本的な検証チェックリスト

以下を確認してください：

要素は意図されたArchiMate 4メタモデルに属していること
関係は意味的に適切であること
廃止されたArchiMate 3.2の概念が誤って導入されていないこと
多重度値が有効であること
すべての主要な能力はビジネス成果と関連付けられていること
重要なアプリケーションはビジネスサービスを実現または支援していること
技術要素はアプリケーションコンポーネントまたはサービスを支援していること
作業パッケージは目標状態アーキテクチャに貢献していること
ギャップは移行作業と関連付けられていること
名称は一意かつ意味があること
図には必要な場合に凡例があること

12.2 Visual Paradigm 検証の実行

バージョンに応じて、次のようなコマンドを使用してください：

ツール > モデルの検証

またはツールウィンドウの対応するモデル検証コマンドを使用してください。

検証ツールは、サポートされていない要素、無効な関係、およびその他のモデルの不整合を特定できます。

12.3 意味論的レビュー

ツールによる検証では、モデルが現実を反映しているかどうかを判断することはできません。次の関係者とレビューを実施してください：

ビジネスオーナー
アプリケーションオーナー
インフラストラクチャオーナー
セキュリティ代表者
データオーナー
プログラムまたはポートフォリオマネージャー

質問してください：

アーキテクチャは事実上正しいですか？
関係は意味がありますか？
その視点（ビューポイント）は、対象読者にとって理解しやすいですか？
現状と目標状態は明確に区別されていますか？
前提条件は文書化されていますか？
所有権とライフサイクルのフィールドは完全に埋められていますか？

13. ArchiMate 3.2からの移行

Visual ParadigmはArchiMate 3.2とArchiMate 4のダイアグラムの共存をサポートしているため、移行は一度に大規模に行うのではなく、段階的に行うことができます。

推奨される移行手順

プロジェクトをバックアップしてください。
Visual ParadigmのバージョンとArchiMateのバージョンを記録してください。
既存のArchiMate 3.2ダイアグラムを棚卸ししてください。
ダイアグラムを以下のように分類してください：
- 変更なしで維持
- 段階的に更新
- 再構築
- 廃止
ArchiMate 4のパッケージ構造を作成してください。
アプリケーション、機能、ビジネスオブジェクトなど、安定した概念を再利用してください。
廃止または統合された要素は、意味に基づいて置き換えてください。
関係を手動でレビューしてください。
実際の制約を表す場合にのみ、多重度を追加してください。
モデル検証を実行してください。
アーキテクチャチーム向けに移行メモを公開してください。

移行マッピングの例

ArchiMate 3.2の使用	ArchiMate 4のアプローチ
業務固有のプロセス	文脈に適切な汎用プロセス概念を使用してください
アプリケーション固有のサービス	関連する再利用可能なサービス概念を使用してください
技術固有の相互作用	コラボレーション、サービス、フロー、または他の意味的に正しい関係を使用してください
制約	要件、原則、または他の適切な動機付け概念を検討してください
ギャップ	動機付けと実装の概念を通じて問題を表現してください
構成	現在のメタモデルに従い、適切であれば集約またはグループ化を使用してください
層ベースの図	ドメインまたは利害関係者の視点として再構成してください

視覚的な類似性のみに基づいて移行しないでください。移行はアーキテクチャの意味を保持すべきです。

14. ドキュメント作成と公開

モデルは、利害関係者がアクセスして理解できる場合にのみ有用です。

14.1 ドキュメントの生成

以下を含めてください:

アーキテクチャの概要
スコープと前提条件
利害関係者
動機付け
現状のアーキテクチャ
目標状態のアーキテクチャ
ギャップ分析
ロードマップ
アプリケーションカタログ
テクノロジーカタログ
リスクと意思決定
用語集
図索引

すべての重要な要素に対して一貫したドキュメントフィールドを使用してください。

14.2 図の公開

Visual Paradigmは、利害関係者と図を共有するためのプロジェクト公開およびオンライン表示機能を備えています。

公開前：

ドラフト専用の図を削除する
図を「現在」「提案中」または「廃止」にマークする
バージョンと所有者情報を追加する
通常のズーム倍率で可読性を確認する
機密性の高い技術詳細が対象読者に適切であることを確認する
アーキテクチャ以外の利害関係者のために用語集を含める

14.3 図のタイトルブロック

以下の情報を含むタイトルブロックを使用する：

図：
視点：
所有者：
ステータス：
バージョン：
最終レビュー日：
対象読者：
範囲：

15. チームの協働とガバナンス

最初から基本的なリポジトリガバナンスを定義する。

推奨される役割

役割	責任
エンタープライズアーキテクト	原則、リポジトリ構造、およびドメイン間の整合性を担当する
ドメインアーキテクト	ビジネス、アプリケーション、データ、または技術ドメインを担当する
モデルライブラリアン	再利用可能な要素、命名規則、およびメタデータを維持する
ソリューションアーキテクト	ソリューション固有のアーキテクチャを維持する
ビジネスオーナー	ビジネス機能とプロセスを検証する
レビューボード	重要なアーキテクチャ決定を承認する

レビュー状態

管理されたライフサイクルを使用する：

ドラフト → 審査中 → 承認済み → 公開済み → 代替済み → 廃止

アーキテクチャ意思決定記録

重要な意思決定については、以下を記録する：

意思決定のタイトル
背景
検討された選択肢
意思決定
根拠
結果
関連するArchiMate要素
所有者
承認日
見直し日

意思決定を、影響を受ける目標、原則、要件、アプリケーション、または作業パッケージにリンクする。

16. 一般的なモデリングの誤り

企業全体を一つのダイアグラムで表現する

これにより、読み取り不可能なモデルが作成されます。再利用可能な要素で接続された、複数の焦点を絞った視点を使用してください。

利用可能なすべての要素を使用する

要素を増やすことが自動的に優れたモデルを生むわけではありません。懸念を伝えるのに必要な最小限の語彙を使用してください。

ArchiMateをフローチャート言語として扱う

ArchiMateの関係は、アーキテクチャの構造と依存関係を記述します。詳細な運用シーケンスは、BPMN、UMLアクティビティ図、または他の専門モデルに属します。

重複の描画

別々のダイアグラムで「CRMプラットフォーム」を繰り返し再作成すると、名前やメタデータが不整合になります。同じリポジトリ要素を再利用してください。

すべてのものにアソシエーションを使用する

関係が真に未指定である場合、アソシエーションは有用です。意味がわかっている場合は、より正確な関係を使用してください。

現在の状態と目標の状態を説明なしに混在させる

色、段階、ライフサイクルメタデータ、または別々のビューを使用して、現在のアーキテクチャ、移行中のアーキテクチャ、および目標のアーキテクチャを区別してください。

サポートされていないArchiMate 3.2の概念を追加する

ArchiMate 4のパレットを使用する際は、それらのステータスと意図された代替を確認せずに、古い概念を新しいダイアグラムにコピーしないでください。

多重性の過剰使用

多重性は、実際のアーキテクチャの制約を表現すべきです。単にダイアグラムを形式的に見せるために追加されるべきではありません。

ツールのレイアウトをアーキテクチャと見なすこと

自動レイアウトは可読性を向上させることができますが、正しいアーキテクチャの意味を決定することはできません。アーキテクトは要素、関係、視点、およびスコープを定義する必要があります。

17. 推奨されるアーキテクチャモデリングワークフロー

ほとんどのイニシアチブに対して、この反復可能なワークフローを使用してください：

スコープと利害関係者を定義する。
リポジトリパッケージ構造を作成する。
原則、駆動要因、評価、および要件を記録する。
戦略的機能と価値連鎖をモデル化する。
現在のビジネス、アプリケーション、およびテクノロジーアーキテクチャをモデル化する。
ギャップとリスクを特定する。
目標アーキテクチャをモデル化する。
作業パッケージ、段階、納品物、および移行イベントを定義する。
利害関係者固有の視点を作成する。
モデルを検証する。
ドメイン所有者とレビューを行う。
ドキュメントを生成する。
承認されたビューを公開する。
所有権、ライフサイクル、およびレビュー日付を維持する。

18. 実用的な品質チェックリスト

ArchiMate 4 モデルを承認する前に、確認してください：

スコープ

モデルの目的が明記されている。
対象者が明確である。
アーキテクチャの境界が明確である。
現状、目標、または移行状態が特定されている。

コンテンツ

目標は要件または原則と関連付けられている。
機能は戦略的方向性と関連付けられている。
ビジネスサービスはアプリケーションによってサポートされている。
アプリケーションはテクノロジーによってサポートされている。
ギャップは実装作業に関連付けられています。
重要なデータオブジェクトには所有者と分類があります。

関係

関係タイプは意図された意味を表現します。
関係は不要に図を横切りません。
多重性は正当化される場合のみ使用されます。
廃止された概念はArchiMate 4の図にコピーされていません。

プレゼンテーション

図には明確なタイトルがあります。
凡例は色と記号を説明します。
レイアウトは読みやすい方向に従っています。
交差と不要な接続は最小限に抑えられています。
図は口頭での説明なしで理解できます。

ガバナンス

モデルには所有者がいます。
レビューステータスが記録されています。
バージョンとレビュー日付が表示されています。
再利用可能な要素は中央に保存されています。
図は関連するドキュメントまたは意思決定とリンクされています。

19. 最終推奨事項

Visual ParadigmでのArchiMate 4の成功した導入のために：

企業全体をモデル化するのではなく、小さなビジネス問題から始めてください。
アプリケーションとインフラストラクチャを設計する前に、動機付けと戦略ビューを使用してください。
共通ドメインは、不要な重複を避ける方法として扱ってください。
再利用可能な標準要素を作成してください。
複雑さを制御するためにビューポイントを使用してください。
実際のルールを表現する場合のみ、多重性を適用してください。
ArchiMateはアーキテクチャレベルに保ち、詳細についてはBPMN、UML、およびデータモデルとリンクしてください。
ArchiMate 3.2モデルは段階的に移行してください。
メタモデルの正確性とビジネスの正確性の両方を検証してください。
必要なステークホルダーグループに対して図を公開する。
命名、所有権、ライフサイクル、およびレビューの規約を早期に確立する。

最も効果的なArchiMate 4リポジトリは、図が最も多いものではありません。それは、各図が特定の問いに答え、各要素が明確な意味を持ち、関係性が動機から戦略、アーキテクチャ、そして実装までのトレーサビリティを提供するものです。

参照

第II部：Visual Paradigmによる実践モデリング: ツールの最初のステップ、コアモデリング技術、およびArchiMateのためのクリーンな図作成の習慣を網羅した実践ガイド。
包括的チュートリアル：ArchiMate図の描き方: 病院の患者退院の例を用いて、ゼロからArchiMate図を作成する手順を段階的に解説するチュートリアル。
包括的チュートリアル：Visual Paradigm DesktopにおけるAI搭載のArchiMate図生成: AI図生成器を使用して、完全に準拠したArchiMateモデルと公式のビューポイントを瞬時に作成する方法を解説します。
実践：単一のトピックからのマルチレイヤーモデル生成: AIを使用して、単一のトピックまたはシナリオからマルチレイヤーのArchiMateモデルを生成する方法を実演します。
ArchiMateビューポイント：移行ビューポイント: 移行ビューポイント、そのステークホルダー、懸念事項、およびベースラインからターゲットアーキテクチャへの移行をモデル化する方法を適用する方法を説明します。
固有の組織基準のためのカスタムビューポイントの作成: ビューポイント管理ツールを使用して、特定の組織ニーズに合わせたユーザー定義のビューポイントを設計する方法を説明します。
第V部：高度な統合とフレームワーク: TOGAF ADM、UML、SysML、およびBPMNとのArchiMateの統合を扱い、標準横断のトレーサビリティをカバーします。
PlantUMLを使用したArchiMateライブラリシステム図の構築: コードとしての図ワークフローのためのチュートリアルで、PlantUMLを使用してマルチレイヤーのArchiMateモデルを構築します。
ネイティブAIによるArchiMate 4生成とビューポイント | Visual Paradigm Desktop: デスクトップアプリケーションでフルビューポイントサポートを備えたネイティブArchiMate 4図のAI搭載生成を発表する公式リリース。
Visual Paradigmによるエンタープライズアーキテクチャの習得：AI駆動型ArchiMateモデリングへのユーザーの道: AI生成、要素の再利用、構文検証、および共通ドメインへの移行を網羅した実践的なユーザー体験。
チュートリアル：Visual ParadigmのAIチャットボットを使用したArchiMate 4図の生成とインポート: AIチャットボットを使用してArchiMate 4図を生成し、デスクトップアプリにインポートする手順を段階的に解説するチュートリアル。
ArchiMate 4ガイド – エンタープライズアーキテクチャの進化 | Visual Paradigm: ヘキサゴニオンフレームワーク、統一された行動概念、およびドメインベースのアーキテクチャに関する詳細ガイド