ArchiSurance ケーススタディは、ArchiMate® モデリング言語を TOGAF® フレームワーク内でどのように使用するかを説明するために作成されたフィクションの例です。このケーススタディでは、3つの以前独立していた企業の合併によって設立された保険会社である ArchiSurance を対象としています。ケーススタディでは、企業のベースラインアーキテクチャについて説明し、その後に複数の変更シナリオを示しています。

このケーススタディは、認定 ArchiMate 講習会での例として必須です。ただし、公式 TOGAF 定義の一部ではありません。この取り組みは、TOGAF と ArchiMate の標準を組み合わせて使用することで、異なる組織、システム、プログラム間でアーキテクチャ情報の一貫した表現を可能にするという The Open Group の境界のない情報フローのビジョンを支援しています。

はじめに

このフィクションのケーススタディは、TOGAF フレームワーク内での ArchiMate 企業モデリング言語の実用的な使用法を示しています。ケーススタディの対象は、異なる都市部でそれぞれ独立して運営していた3社の合併によって生まれた保険会社である ArchiSurance です。

このケーススタディは、認定 ArchiMate 講習会の全期間を通じて例として使用され、ArchiMate 資格試験の背景資料としても機能します。適切な ArchiMate または TOGAF の視点を使用して、ベースラインのビジネス、アプリケーション、データ、技術アーキテクチャから始めます。その後、2つの変更シナリオに進みます。最初のシナリオでは、TOGAF アーキテクチャ開発および実装プロセスを示すビューの例を提供します。アーキテクチャのビジョン、ビジネス目標、原則および要件、ターゲットのビジネス・アプリケーション・データ・技術アーキテクチャ、ベースラインとターゲット間のギャップ分析の結果、実装および移行計画を支援するビューを示します。2番目のシナリオでは、最初のシナリオのターゲット状態を新たなベースラインとして採用し、顧客がウェブ経由で自らの保険ポートフォリオに直接アクセスできるようにします。このシナリオについては、現在、モデルは用意されていません。

The Open Group は、このケーススタディが時間とともに進化することを期待しており、メンバーに対し、元のケース記述およびモデルと整合性を保った範囲で、新たな側面やビューを追加したり、新しい変更シナリオを作成することを奨励しています。

TOGAF® および ArchiMate®

企業アーキテクチャフレームワークは、企業アーキテクトを支援するさまざまな側面をカバーしています。その他のものとして、以下のいずれかの組み合わせを含む可能性があります：

• アーキテクチャ作成のためのプロセス（「仕事のやり方」）
• 視点のコレクションまたは分類
• アーキテクチャを記述するための言語（概念と関係を定義するだけでなく、記号も含む）

The Open Group は、企業アーキテクチャのための2つのオープン標準を維持しています：TOGAF [1] および ArchiMate [2]。

TOGAF の核となるのは、企業アーキテクチャの開発および実装のためのプロセスであるアーキテクチャ開発手法（ADM）です。TOGAF はまた、視点、技術、参照モデル、およびアーキテクチャを構成する構成要素の種類を特定するためのコンテンツフレームワークについても記述しています。ただし、TOGAF はアーキテクチャビューを作成する際に特定のモデリング言語を使用することを規定していません。

ArchiMate は、アーキテクチャ開発サイクル全体を支援するためのモデルの均一な表現を提供する図式言語です。標準のバージョン2.0には、実際のアーキテクチャ（ビジネス、情報システム、技術アーキテクチャ、およびそれらの間の関係）を記述することを目的としたコア言語に加え、アーキテクチャの動機、実装および移行計画をモデリングするための拡張機能が含まれています。図1は、コア言語と拡張機能が TOGAF ADM とどのように関連しているかを示しています。モデリングの概念と関係を定義するだけでなく、TOGAF と同様に、ArchiMate もアーキテクチャの視点のセットを定義しています。

図1：ArchiMate と TOGAF の対応関係

TOGAF と ArchiMate は、単一の基盤となるアーキテクチャモデルのさまざまな側面を捉え、伝えるために視点を用いるという哲学において、堅固な共通の基盤を持っています。これらの標準は互いに補完し合う関係にあります。TOGAF はアーキテクチャの開発および実装プロセスに焦点を当てているのに対し、ArchiMate はアーキテクチャアーティファクトをモデリングするための均一な言語に焦点を当てています。

Technical Standard [2] に記載されているように、ArchiMate 言語は、ベンダーアンビエントな概念と関係、図式表記を含むセットを提供することで、TOGAF [1] を補完し、一貫性があり統合されたモデルを構築するのを支援します。これらのモデルはビューの形で表現できます。

背景

ArchiSurance [3,4] は、最近行われた3つの以前独立していた保険会社の合併の結果です：

• Home & Away：住宅および旅行保険に特化
• PRO-FIT：自動車保険に特化
• Legally Yours：法的費用保険に特化

現在、同社は、独立していた前身と同名で、同様の本部を持つ3つの部門から構成されています。

図2：ArchiSurance：3つの保険会社の合併の結果

ArchiSurance は、3社間の多数のシナジーを活用するために設立されました。3社の合併前には異なる種類の保険を販売していましたが、ビジネスモデルは類似していました。3社すべての製品は、ウェブ、メール、電話、郵送チャネルを通じて、消費者および中小企業に直接販売されていました。本社は異なる都市に所在していましたが、それぞれが都市部の近代的なオフィスビルに完全に設置されていました。各社は忠実な顧客層を持ち、誠実さ、価値、サービス、財務安定性の面で良好な評判を獲得していました。3社とも、機関投資家および個人投資家の連鎖によって私営で運営されていました。

3社の主要投資家は、低コストの競合が市場に参入し、成長が著しい地域に新たな機会が生まれ、各社が競争力を維持するために大幅な新しいIT投資が必要であることに気づいた後、合併交渉を開始しました。彼らは、コストを同時に制御し、顧客満足度を維持し、新しい技術に投資し、成長可能性の高い新市場を活用できるのは、規模の大きな合併企業だけであることに気づきました。合併交渉および規制承認には18か月を要しましたが、契約書は2年前に署名され、合併は完了しています。

新会社は、合併前の3社のすべての保険商品を提供し、市場状況の変化に応じて頻繁に商品を調整する予定です。3社の前身と同様に、ArchiSurance は印刷物、ウェブ、ダイレクトマーケティングを通じて顧客に直接販売しています。

合併は、新会社のビジネスプロセスおよび情報システムにおける多くの統合および調整の課題を生じさせました。これらの課題は、ArchiSurance のベースラインビジネス、アプリケーション、データ、技術アーキテクチャに明確に現れています。しかし、まず最初に TOGAF ADM の初期フェーズが、これらの課題の動機的文脈を確立しました。

初期フェーズ

将来のビジネスおよびITの変化をガイドするために、ArchiSuranceは最小限のカスタマイズでTOGAF 9.1およびArchiMate 2.0に基づく企業アーキテクチャの開発を決定した。

予備フェーズの一環として、アーキテクチャ関与における主要ステークホルダーおよびその懸念が特定された（ArchiMateでは内部ドライバーとしてモデル化された）。TOGAFでは、これを表すためにステークホルダー・マッピング・マトリクスを定義している。ArchiMateでは、ステークホルダー・ビューを使用してこれを表現できる：

ステークホルダー・ビューは、アナリストがステークホルダー、その懸念、およびそれらに対する評価（強み、弱み、機会、脅威の観点から）をモデル化することを可能にする。さらに、これらの懸念や評価を、それらを解決するための初期（高レベルの）目標と関連付けることもできる。

図3はそのような図の一部を示しており、2つのステークホルダー（アーキテクチャ委員会およびその現在および潜在的な顧客）とそれらの懸念を特定しており、ドライバーとしてモデル化されている。顧客満足度は両方のステークホルダーが共有する懸念である。ステークホルダー満足度は、より詳細な懸念に分解できる。たとえば利益である。

図3：ステークホルダー・ビューの一部

ドライバーは、利益を達成するために以下の通り、特定のビジネス目標の開発につながる。コスト削減などの目標は、保守コストの削減と人件費の削減に分解できる。

図4：利益を促進するビジネス目標

ArchiMateでは、原則を、特定の文脈におけるすべてのシステム、またはそれらの実現方法に関する規範的性質として定義する。ここでいう「システム」はITシステムだけでなく、組織や組織単位も含むことに注意する。したがって、原則はビジネス目標の実現を支援する。TOGAFでは、原則を、アーキテクチャが満たすべき意図の質的表明として定義する。原則には、支援する根拠と重要な含意が必要である。

ArchiMateの原則ビュー（図5に例を示す）は、原則、それらの依存関係、およびそれらが実現する目標を視覚的に記述する：

原則ビューは、現在の設計問題に関連する原則、およびそれらの原則を動機づける目標をモデル化することをアナリストやデザイナーに可能にする。さらに、原則と目標の間の関係をモデル化できる。たとえば、原則は互いに正または負の影響を与える可能性がある。

図5：原則ビュー

TOGAFは、原則の概要を提供するために原則カタログを定義する。

フェーズB：ベースライン・ビジネス・アーキテクチャ

合併後、ArchiSuranceは、販売およびカスタマーサービスのためのマルチチャネル・コンタクト・センターとして、共有フロントオフィスを設立した。主要なコンタクト・センターは、元のHome & Away本社に位置している。3つの独立したバックオフィスは、元の3社の保険商品を引き続き処理している。文書処理のための共有サービスセンター（SSC）が、元の収益性の高かった本社に設立された。このセンターは、中央文書リポジトリおよびすべての自動化された文書ワークフローを管理している。さらに、法的拘束力を持つ文書がArchiSuranceに入出庫する際のすべてのスキャン、印刷、アーカイブ作業を実施している。業務継続性を確保し、ピーク時の業務を処理するために、SSCにはフロントオフィス機能を実行できる訓練を受けた人員および設備が備えられており、フロントオフィスも同様に準備が整えられている。

図6：ArchiSuranceのグローバル組織構造

TOGAF ADMのフェーズB（ビジネスアーキテクチャ）において、ArchiMateはArchiSuranceの組織構造、製品、サービス、機能、プロセス、情報などを表現および関連付けることができる。ビジネスアーキテクチャは、データ、アプリケーション、技術アーキテクチャの文脈を提供する。

組織構造

組織構造を記述するために、ArchiMateは組織ビューを定義する：

組織ビューは、企業、部門、ビジネスネットワーク、またはその他の組織的実体の（内部）組織に焦点を当てる。このビューでは、モデルをネストされたボックス図として表現できるが、より伝統的な表現方法である組織図も使用できる。組織ビューは、組織内の能力、権限、責任を特定するのに非常に有用である。

このビューに相当するTOGAFのものとして、組織分解図がある。

組織構造は通常、図7に示すようにツリー形式で表現されるが、ArchiMateおよびTOGAFで使用される組織分解手法は、単純なツリー形式の組織図よりも多くの選択肢を提供する。このビューは、ArchiSuranceの上位レベルの組織構造、主要な拠点および部門を示している。あるいは、ネストされた図を使用して、拠点や部門ごとに組織を分割することもできる。

図7：組織ビュー

ビジネス機能

ArchiMateのビジネス機能は、選択された基準（通常は必要なビジネスリソースおよび／または能力）に基づいて行動をグループ化する。

ArchiSuranceが区別する主なビジネス機能は以下の通りである：

• マーケティング — 製品およびセグメントの研究、計画、プロモーション、管理、および保険数理士と協力して製品を設計すること
• 保険数理士 — 製品価格および準備金水準の決定、マーケティングと協力して新製品の設計、企業リスクの分析
• カスタマーリレーションズ — ArchiSuranceと顧客とのやり取り；顧客の質問対応、受領した請求の記録、ダイレクトマーケティングキャンペーンの実施
• 保険審査 — 個別保険の価格設定および保険提案書および保険契約の作成
• 請求処理 — 各保険契約に対する請求に対して、ArchiSuranceの対応策を策定および実行すること
• 財務 — 契約に基づく顧客からの保険料の定期的徴収および保険請求の支払い処理
• 文書処理 — ドキュメントのスキャン、印刷、アーカイブを通じて他の機能を支援
• 投資運用 — 企業および規制上の流動性およびリスク制約の範囲内で最大のリターンを達成するための金融資産および不動産資産の管理

これらのビジネス機能の一部は、ArchiSuranceの3つの部門のバックオフィスで複製されている

ビジネス機能およびそれらの関係をモデル化するため、ArchiMateはビジネス機能ビューを定義している：

ビジネス機能ビューは、組織の主要なビジネス機能およびそれらの情報フロー、価値フロー、または物品フローに関する関係を示す

このビューに相当するTOGAFのものは、機能分解図である

図8は、ArchiSuranceの主要なビジネス機能、機能間および外部役割間の重要な情報フローを示している。また、異なる部門のバックオフィスにおけるビジネス機能の複製も示している

図8：ビジネス機能ビュー

ビジネスプロセス

ArchiMateのビジネスプロセスは、活動の順序に従って行動をグループ化する。一定の製品またはサービスのセットを生成する。プロセスアーキテクチャは、最も重要なビジネスプロセスおよびそれらの関係を示す。また、各プロセスの主要なステップも示すことがある。通常、プロセスフローのすべての詳細は示さない — それはビジネスプロセスモデリング言語の目的である。ArchiMateはビジネスプロセスビューを定義している：

ビジネスプロセスビューは、1つ以上のビジネスプロセス（またはその一部）の高レベル構造および構成を示すために使用される

このビューに相当するTOGAFのものは、プロセス図である

図9は、ArchiSuranceの2つのコアビジネスプロセスとその高レベルのサブプロセスを示している：契約締結（新しい保険商品を販売する際に行われる）および請求処理（損害請求を受けた際に行われる）。これらのプロセスの詳細は保険商品の種類によって異なる場合があるが、主要なステップは同じである

図9：ビジネスプロセスビュー

フェーズC：ベースライン情報システムアーキテクチャ（アプリケーション）

合併以降、3つの部門は共通のポータル、コントラクトセンター用ソフトウェアスイート、および文書管理システムを導入した。さらに、企業は戦略的なCRMソリューションを選定し、Home & AwayおよびPRO-FITに導入した。しかし、経営陣は合併後のリスクを最小限に抑えつつ、各部門の日常的なパフォーマンスを継続的に改善することに注力していたため、コアビジネスアプリケーションの合理化はまだ開始されていない。今やArchiSuranceは合併後のパフォーマンス目標を達成したため、投資家は共通の製品および顧客中心のアプリケーションの導入によって大幅なITコスト削減を期待している。課題は残っている。Home & Awayはまだ合併前の保険管理および財務アプリケーションパッケージを使用している一方、PRO-FITおよびLegally Yoursはまだ自社の合併前のカスタムアプリケーションを使用している

図10：アプリケーション環境

アプリケーション協働

ArchiMateは、アプリケーションの全体像およびアプリケーション間の依存関係を把握するためのアプリケーション協働ビューを定義している：

アプリケーション協働ビューは、アプリケーションコンポーネント間の関係、すなわちそれらの間の情報フロー、または提供および使用するサービスを記述する。このビューは、通常、組織のアプリケーション環境の概要を作成するために使用される。また、ビジネスプロセスの実行を支援するためのサービスの（内部）協働またはオーケストレーションを表現するためにも使用される

このビューに相当するTOGAFのものは、アプリケーション通信図である

図11は、ArchiSuranceの主要なアプリケーションおよびアプリケーション間の主要なデータフローを示している

図11：アプリケーション協働ビュー

ビジネス-アプリケーション整合

TOGAFはビジネス-アプリケーション整合のための図を定義していない。しかし、ビジネスとアプリケーションアーキテクチャの間の関連を示す行列ベースのビューを指定している。例えば、アプリケーション/組織行列およびアプリケーション/機能行列である

アプリケーションコンポーネント間の関係は、グラフィカルにモデル化することもできる。ArchiMateはアプリケーション使用ビューを定義している：

アプリケーション使用ビューは、アプリケーションが1つ以上のビジネスプロセスを支援するためにどのように使用されるか、および他のアプリケーションによってどのように使用されるかを記述する。ビジネスプロセスおよび他のアプリケーションが要求するサービスを特定することでアプリケーションを設計するのにも使用できる。また、利用可能なサービスを記述することでビジネスプロセスを設計することもできる。さらに、ビジネスプロセスがアプリケーションに依存していることを特定しているため、これらのプロセスを担当する運用マネージャにとって有用である

アプリケーションサービスの概念はこのビューにおいて中心的な役割を果たす。図12は、ArchiSurance Home & Away部門で使用されているアプリケーションが提供するサービスのサブセットを示しており、請求処理プロセスのどのサブプロセスがこれらのサービスのどれを使用しているかを示している

図12：アプリケーション使用ビュー

フェーズC：ベースライン情報システムアーキテクチャ（データ）

ArchiSuranceのデータアーキテクチャは、その概念的ビジネスオブジェクトと論理的データオブジェクトの主な関係を記述している。ArchiMateはこの目的のために情報構造ビューを定義している：

情報構造ビューは、ほぼすべての情報システム開発プロセスで作成される従来の情報モデルと同等である。これは、企業または特定のビジネスプロセスやアプリケーションで使用される情報の構造を、データ型または（オブジェクト指向の）クラス構造の形で示す。

TOGAFで定義されたデータビューの一つが論理データ図である。

図13は、ArchiSuranceが定義したビジネスオブジェクトのサブセットを示している。顧客情報の一部は保険ファイルであり、保険申込、保険契約、損害請求から構成されている。ArchiSuranceが販売する各保険種別ごとに、保険契約オブジェクトの多数の特殊化が定義されている。

図13：情報構造ビュー

TOGAFで定義されたもう一つのデータビューがデータ配信図である：

データ配信図の目的は、データエンティティ、ビジネスサービス、アプリケーションコンポーネントの間の関係を示すことである。この図は、アプリケーションコンポーネントが論理的エンティティをどのように物理的に実現しているかを示す。これにより、ITインフラの効果的なサイズ設定と最適化が可能になる。さらに、データにビジネス価値を割り当てることで、アプリケーションコンポーネントのビジネス上的重要性を示す手がかりを得ることができる。

図14は、ArchiSuranceのアプリケーション向けのデータ配信図を示している。

図14：データ配信図

フェーズD：ベースライン技術アーキテクチャ

図15は、ArchiSuranceの技術インフラストラクチャの概要を示している。フロントオフィス（ホーム＆アウェイ本社に位置）には共通サーバーとWebホスティング専用サーバーがある。PRO-FIT本社に位置する共有サービスセンター（SSC）には独自のファイル管理システムサーバーがある。3つのバックオフィスそれぞれに、そのアプリケーション用のサーバーがある。

ローカルエリアネットワーク（LAN）が、ArchiSuranceの3か所の拠点にあるサーバーと個人用コンピュータを接続しており、それらはさらに企業用広域ネットワーク（WAN）によって接続されている。

図15：インフラストラクチャの概要

インフラストラクチャの概要を把握するため、ArchiMateはインフラストラクチャビューを定義している：

インフラストラクチャビューは、アプリケーション層を支援するソフトウェアおよびハードウェアインフラストラクチャ要素を含む。具体的には、物理デバイス、ネットワーク、システムソフトウェア（例：オペレーティングシステム、データベース、ミドルウェア）などが含まれる。

このビューに相当するTOGAFのビューは、環境と場所図である。

図16は、ArchiSuranceの主要インフラストラクチャコンポーネントを場所と部門別にグループ化して示している。このビューは、異なるデバイスを接続するネットワークおよびデバイス上に展開された（アプリケーション）アーティファクトも示している。

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

変更シナリオ

シナリオ1：アプリケーションポートフォリオの合理化

ArchiSuranceのアプリケーションアーキテクチャの不柔軟性により、変化するビジネス状況への対応が困難になっている。合併の影響もあり、アプリケーション環境が分散化し、データの重複や機能の重複が生じ、さまざまなデータ形式や方法を用いた点対点のアプリケーション統合が行われている。これらの問題は、内部の不安定性、アプリケーションの保守コスト増加、社内およびパートナーとの情報共有の妨げを引き起こしている。その結果、IT部門には大量の作業依頼の残積がある。ArchiSuranceの上層経営陣は、この残積に強く懸念しており、特に多くの契約販売パートナーや影響力のある保険アドバイザーと情報の自動共有ができない点に強い関心を寄せている。

このシナリオは、ArchiSuranceのアプリケーションポートフォリオを以下のように合理化する：

• ポリシー管理や財務取引などの機能を実行する統合バックオフィススイートへの移行。スイートには以下のものが含まれる：
  • 提案書および保険契約を生成する自動化された審査システム — AUTO-U
  • 自動化された審査システムと統合されたパッケージ化されたポリシー管理システム。保険契約の発行、変更、更新を担当。また顧客会計および請求処理も行う — P-ADMIN
  • スクリーンおよびワークフローがカスタマイズ可能で、ArchiSuranceの3つの事業分野をサポートするパッケージ化された請求システム — VERSA-CLAIM
  • すべての保険商品を定義し、それらの定義をAUTO-U、P-ADMIN、VERSAC-CLAIMにWebサービス経由で公開する製品構成管理システム — P-CONFIG
  • ルールリポジトリ、処理エンジン、ルール開発環境、ルール管理UI用の作成ツールから構成されるビジネスルール管理システム（BRMS）。ビジネスルールエンジンは、ルール実行機能をAUTO-U、P-ADMIN、VERSAC-CLAIM、P-CONFIGにWebサービス経由で公開する — EDGE
• 戦略的CRMシステムへの移行を完了する

ArchiSuranceの主要投資家およびCEOは、ArchiSuranceの顧客およびパートナーが変更を一切感じないことを条件にこれらの計画を支持しています。保険会社の製品およびサービスに影響が及んではならず、すべての顧客およびパートナーとのやり取りは中断なく継続されるべきです。

図17：アプリケーションポートフォリオの合理化

この取り組みの一環として、技術基盤も簡素化されます。別々のバックオフィスサーバーは、ホーム＆アウェイ本社のデータセンターに設置された共有サーバークラスタに置き換えられます。ただし、事業継続を確保するため、PRO-FIT本社のデータセンターにもバックアップサーバークラスタを設置します。

フェーズA：アーキテクチャビジョン

TOGAF ADMのフェーズAは、範囲、制約、目標を設定することでアーキテクチャ作業を確立し、アーキテクチャ開発サイクルの反復を開始します。このフェーズではビジネス文脈の検証も行い、アーキテクチャ作業文書を策定します。

ビジネス文脈は、主要なビジネス目標およびアーキテクチャ原則に基づく重要なビジネス要件で構成されています。図18は、現在のシナリオに関連するいくつかのビジネス目標と原則を示しています。

図18：ビジネス目標と原則

目標と原則は、ArchiMateのゴール精査ビューに示すように、具体的な要件の基礎となります。

ゴール精査ビューは、設計者が（高レベルの）目標をより具体的な目標に精査する様子、および具体的な目標を目標の実現に必要な特性を記述する要件や制約に精査する様子をモデル化できるようにします。集約関係は、目標をサブゴールに精査するために使用されます。実現関係は、目標を要件に精査する様子をモデル化するために使用されます。

図19は、現在の変更シナリオにおけるこのビューの例を示しています。

図19：ゴール精査ビュー

アーキテクチャビジョンの重要な要素の一つは、ステークホルダーにアーキテクチャ作業の付加価値を説明するために、ベースラインおよびターゲットアーキテクチャの高レベル表現を提供することです。この目的のために、ArchiMateはイントロダクタリービューを定義しています。

イントロダクタリービューは、完全なArchiMate言語のサブセットを構成する簡略化された記法を使用します。設計プロセスの初期段階で、すべての詳細がまだ必要でない場合や、非アーキテクト向けにアーキテクチャモデルの本質をよりシンプルで直感的な記法で説明する際に通常使用されます。この基本的で形式の少ないビューのもう一つの用途は、アーキテクチャ設計がすでに固定されているという印象を避けることです。これは、より形式的で構造的または詳細な可視化を使用する際に簡単に生じる印象です。

このビューに相当するTOGAFのものとして、ソリューションコンセプト図があります。

以下の例は、現在の変更シナリオで必要な最も重要な変更を強調しています：

• フロントオフィスでは、別個の法務費用CRMシステムが廃止されます。
• バックオフィスでは、別個のバックオフィスアプリケーションが単一のバックオフィススイートに置き換えられます。3つの別個の共通バックオフィスサーバーは、1つの共有サーバークラスタと1つのバックアップサーバークラスタに置き換えられます。

図20：イントロダクタリービュー

フェーズB：ターゲットビジネスアーキテクチャとギャップ分析

このシナリオでは、ビジネスアーキテクチャは変更されません。しかし、ビジネスアーキテクチャ内では、ターゲットアーキテクチャが主要なビジネス要件をどのように実現するかを示しています。この目的のために、TOGAFはビジネスフットプリント図を規定しています。ArchiMateでは、このビューは要件実現ビューを使用して表現できます。その定義は以下の通りです：

要件実現ビューは、設計者がビジネスアクター、ビジネスサービス、ビジネスプロセス、アプリケーションサービス、アプリケーションコンポーネントなど、主要な要素によって要件の実現をモデル化できるようにします。通常、要件はゴール精査ビューから生じます。

以下の例は、アーキテクチャビジョンフェーズで設定されたビジネス要件が、アーキテクチャ内の要素によってどのように実現されるかを示しています。

図21：要件実現ビュー

フェーズC：ターゲットアプリケーションアーキテクチャとギャップ分析

以下のアプリケーション通信図は、アプリケーション環境の提案されるターゲット状態を示しています。

図22：ターゲットアプリケーションアーキテクチャ：アプリケーション協働ビュー

アプリケーションアーキテクチャのグローバルギャップ分析の結果を以下に示します。ベースラインアーキテクチャに存在するいくつかのアプリケーションコンポーネントは、ターゲットアーキテクチャでは存在しなくなりました。具体的には、別個のバックオフィスアプリケーションおよび別個の法務費用保険CRMシステムです。法務費用保険顧客向けのCRM機能は、共通CRMシステムに移管されるため、新たなコンポーネントは必要ありません（ただし、既存の共通CRMシステムは調整または再構成が必要な場合がありますが、ギャップ分析には反映されていません）。さらに、完全に新しいバックオフィスアプリケーションスイートが導入されます。

図23：アプリケーションアーキテクチャ：ギャップ分析

フェーズD：ターゲットテクノロジーアーキテクチャとギャップ分析

以下のインフラストラクチャビューは、テクノロジーアーキテクチャ分野における提案されるターゲット状態を示しています。

図24：目標技術アーキテクチャ：インフラストラクチャビュー

図25は、技術アーキテクチャのグローバルギャップ分析の結果を示している。個別の共通バックオフィスサーバーは削除される。Home & Awayの元のサーバークラスタは、中央のArchiSuranceバックオフィスサービスクラスタに変更され、PRO-FIT本社のSSCに追加のバックアップサーバークラスタが設置される。Home & Awayバックオフィスにはバックアップ文書管理サーバーも存在する。新しいバックオフィススイートおよび文書管理システムは、それぞれのプライマリおよびバックアップサーバーにレプリケートされる。

図25：技術アーキテクチャ：ギャップ分析

実装および移行計画

TOGAF 9では、段階EおよびFにおける移行アーキテクチャが導入され、ベースラインと目標アーキテクチャの間の可能な中間状態（「プラトー」）を表している。

ArchiMateでは、ベースライン、目標、移行アーキテクチャおよびそれらの間の関係は、移行ビューを使用して示される：

移行ビューには、既存のアーキテクチャから望ましいアーキテクチャへの移行を指定するために使用できるモデルおよび概念が含まれている。

図26は現在のシナリオの例を示している。ArchiSuranceのIT部門は、バックオフィスシステム統合とCRMシステム統合を並行して実行するための十分なリソースを持っていない。そのため、一つの移行アーキテクチャでは、二つのCRMシステムを一つに置き換えつつ、バックオフィスシステムは別々に保つ。もう一つはバックオフィススイートを備えているが、CRMアプリケーションは二つある。

図26：移行ビュー

移行アーキテクチャは、CRM統合やバックオフィスアプリケーション統合などの実装プロジェクトの計画を支援する。これらのプロジェクトの順序は、どの移行アーキテクチャが選択されるかに依存する。これはTOGAFプロジェクトコンテキスト図（図27）で示すことができる：

プロジェクトコンテキスト図は、広範な変革ロードマップの一部として実現される作業パッケージの範囲を示している。プロジェクトコンテキスト関係図は、プロジェクトによって追加、削除、または影響を受ける組織、機能、サービス、プロセス、アプリケーション、データ、技術と作業パッケージをリンクしている。

図27：ArchiMateで表現されたTOGAFプロジェクトコンテキスト図

シナリオ2：オンラインポートフォリオ管理

このシナリオでは、シナリオ1の目標状態を新たなベースラインとして想定し、顧客はウェブ経由で自分の保険ポートフォリオに直接アクセスできる。顧客に以下の機能を提供することで：

• ArchiSuranceが事業を実施する際に使用するルールに従って、安全にオンラインで住宅保険、旅行保険、自動車保険、または法的費用保険を購入、更新、または変更できる
• オンライン取引に関する支援を以下の方法で得られる：
  • 知識ベースで回答を検索する
  • カスタマーサービス担当者（CSR）とのチャットセッションを開始する
  • ウェブフォームを使用してメールを記述・送信し、CSRが返信する
  • ウェブフォームを使用してCSRからの電話連絡を依頼する
• 顧客のニーズに応じて、ArchiSuranceの提携企業から情報および特別オファーを入手できる。たとえば、銀行サービスや財務計画サービス、投資、クレジットカード、その他の保険商品など

このシナリオに対して現在はモデルが用意されていない。The Open Groupは、メンバーが今後のバージョンのこの事例研究に貢献することを奨励している。貢献者は、ここに紹介された二つのシナリオを拡張または詳細化するか、新しいシナリオを作成できる。ただし、一貫した作業成果を促進するため、新しい変更シナリオのベースラインアーキテクチャは、ここに紹介された変更シナリオのベースラインまたは目標アーキテクチャであるべきである。

参考文献

1. TOGAF® バージョン 9.1、The Open Group、The Open Group発行、2011年。
2. ArchiMate® 2.0 規格、The Open Group、2012年1月。
3. Doest, H., Iacob, M.-E., Lankhorst, M.M.（編）、van Leeuwen, D.：ビューの機能性と例、ArchiMate Deliverable D3.4.1a v2、TI/RS/2003/091、Telematica Instituut、エンスケーデ、オランダ、2004年。
4. van den Berg, H., Moelaert, F.：PRO-FIT Autoschade Open Trial Bench、Trial Bench Deliverable WP3/N004/V001、TRC、エンスケーデ、オランダ、1997年。
5. ArchiMateとは何か？
6. 完全なArchiMateビューイングガイド
7. ArchiMate 3のアップデート
8. ArchiMate 3の新機能
9. TOGAF ADMとArchiMateツールの併用方法
10. ArchiMate 3.1におけるバリューストリームの使い方
11. ArchiMate 3.1の新機能