TOGAFとは何ですか？

TOGAF®、オープングループ標準、世界をリードする組織がビジネス効率を向上させるために使用する検証済みのエンタープライズアーキテクチャのメソドロジーやフレームワークです。エンタープライズアーキテクチャの標準として、エンタープライズアーキテクチャ専門家間で一貫性のある標準、手法、およびコミュニケーションを確保し、より良い方法でエンタープライズアーキテクチャの作業を実施できるようにします。具体的には、以下の通りです：
• 最良の実践に基づく反復的なプロセスモデル
• 既存のアーキテクチャ資産の再利用可能なセット
• エンタープライズアーキテクチャの計画、開発、実装、保守に使用する手法とツール

TOGAF開発概要

1995年に初版発行され、TOGAFは米国国防総省の情報管理技術アーキテクチャ枠組み（TAFIM）に基づいています。この基盤の上に、オープングループ・アーキテクチャフォーラムは、定期的にTOGAFの次世代バージョンを発展させてきました。

*ArchiTACTS から http://architacts.com/WP/?page_id=11753

TOGAFの文脈におけるアーキテクチャとは何か？

ISO/IEC 42010:20071では「アーキテクチャ」を以下のように定義しています：

「システムの基本的な構造であり、その構成要素、それらの相互関係および環境との関係、そして設計と進化を規定する原則を体現したもの。」

TOGAFはこの定義を受け入れるとともに拡張しています。TOGAFにおいて、「アーキテクチャ」は文脈によって2つの意味を持ちます：

  1. システムの形式的な記述、または実装をガイドするためのコンポーネントレベルでの詳細な計画
  2. コンポーネントの構造、それらの相互関係、および時間の経過に伴う設計と進化を規定する原則とガイドライン。

 

エンタープライズアーキテクチャとは何か？

エンタープライズアーキテクチャ（EA）は、戦略の成功した開発と実行のために、常に包括的なアプローチを用いて、エンタープライズ分析、設計、計画、実装を実施する明確に定義された実践です。エンタープライズアーキテクチャは、アーキテクチャの原則と実践を適用して、組織がビジネスプロセス, データと 情報、およびテクノロジー戦略を実行するために必要な変化を導くためのものです。これらの実践は、企業のさまざまな側面を活用して、これらの変化を特定し、動機づけ、実現します。その内容には、ビジネスの戦略的意図を理解する努力があり、その後、ビジネスプロセスから支援技術、パートナーシップ関係、あらゆる種類のインフラストラクチャ、採用とトレーニング、その他すべての重要な業務が、より良いビジネスパフォーマンスを達成するために整合されるようにすることを含みます。

 

TOGAFの構造

TOGAFのコンテンツは、7つの部:

  1. はじめに
  2. アーキテクチャ開発手法
  3. ADMのガイドラインと技術
  4. アーキテクチャコンテンツフレームワーク
  5. エンタープライズコンティニュム＆ツール
  6. TOGAFリファレンスモデル
  7. アーキテクチャ能力フレームワーク

7つの部の概要は以下の通りです：

第1部 – はじめに

表に示すように、この部はエンタープライズアーキテクチャの主要な概念、特にTOGAFアプローチについて概略的に紹介しています。それでは、これらの各部のコアコンセプトを確認しましょう：

コアコンセプト

TOGAF 9は、4つの関連するアーキテクチャの開発をカバーしています。これらの4つのアーキテクチャタイプは、全体のエンタープライズアーキテクチャのサブセットとして広く認識されており、TOGAFはすべてのものを支援することを目的としています。

アーキテクチャの種類

  1. ビジネスアーキテクチャ –ビジネス戦略、ガバナンス、組織、および主要なビジネスプロセス。
  2. データアーキテクチャ –組織の論理的および物理的データ資産およびデータ管理リソースの構造。
  3. アプリケーションアーキテクチャ –展開される個々のアプリケーション、それらの相互作用、および組織の主要ビジネスプロセスとの関係を示す設計図。
  4. アーキテクチャ技術アーキテクチャ –ビジネス、データ、アプリケーションサービスの展開を支援するために必要な論理的なソフトウェアおよびハードウェア機能。これにはITインフラ、ミドルウェア、ネットワーク、通信、処理、および標準が含まれます。

注記：情報システムアーキテクチャ = データアーキテクチャ + アプリケーション

TOGAFモジュール構造に関する文書

  • 第2部 – アーキテクチャ開発手法（ADM）はTOGAFの中心的な部分である
  • 第7部 – アーキテクチャ能力はADMを運用する。
  • 第3部 – ADMは多数のガイドラインと技術によって支援される
  • 第4部 – 次のようなコンテンツが生成され、アーキテクチャリポジトリに格納される：成果物、アーティファクト、およびビルディングブロック
  • 第V部 – これらはエンタープライズ連続体に基づいて分類される
  • 第VI部 – リポジトリは最初、TOGAF参照モデルで初期化される

第II部：アーキテクチャ開発手法

これはアーキテクチャ開発手法（ADM）と呼ばれる有名な円である。各フェーズには実行しなければならない一連のステップが含まれている。これはアーキテクチャを開発するための検証済みで繰り返し可能なプロセスを提供する。

  • 準備フェーズ
  • フェーズA：アーキテクチャビジョン
  • フェーズB：ビジネスアーキテクチャ
  • フェーズC：情報システムアーキテクチャ フェーズD：テクノロジー・アーキテクチャ
  • フェーズE：機会と解決策
  • フェーズF：移行計画
  • フェーズG：実装ガバナンス
  • フェーズH：アーキテクチャ変更管理
  • 要件管理

注記：

TOGAFのアーキテクチャフェーズB、C、Dでは、同じステップ（ステップ1～8）を実施しなければならない

ADMナラティブ

TOGAFの各開発フェーズには、以下の図に示すフェーズAと同様に、ガイドを提供する4つの主要なセクションが備わっている

第III部：ADMガイドラインおよび技術

ADMの適用を支援するガイドラインおよび技術のセット。ガイドラインは、異なる状況（例：反復の使用など）や特定の要件（例：セキュリティなど）に対応するためのADMの適応を支援する。技術は、ADM内の特定のタスク（例：原則の定義、ビジネスシナリオ、ギャップ分析、移行計画、リスク管理など）を支援する。これらがADMガイドラインおよび技術で取り上げられるトピックである。

  • ADMにおける反復
  • アーキテクチャ・ランドスケープ
  • セキュリティアーキテクチャ
  • SOA
  • アーキテクチャ原則
  • ステークホルダー管理
  • アーキテクチャパターン
  • ビジネスシナリオとビジネス目標
  • ギャップ分析
  • 移行計画技術
  • 相互運用性要件
  • ビジネス変革の準備状況評価
  • リスク管理
  • 能力ベースの計画

第4部：アーキテクチャコンテンツフレームワーク

本部ではTOGAFコンテンツフレームワーク（TOGAF 9版で新規導入）について説明する。その内容は以下の通りである：

  • TOGAFへの重要な追加
  • アーキテクチャ作業成果物の詳細なモデルを提供する
  • TOGAFの出力における一貫性を高める

コンテンツメタモデル

コンテンツフレームワークは、ビルディングブロックの種類、関係性、属性について構造化されたモデルを提供し、非公式に使用するか、企業アーキテクチャモデリングツールの設定の基盤として使用できる。TOGAF内でのアーキテクチャの基本要素としてビルディングブロックが引き続き使用される一方で、コンテンツフレームワークはコアと拡張の概念を特徴とし、オプションのビルディングブロック種別を備えることで、軽量および詳細なアーキテクチャの両方をサポートする。これによりTOGAFに以下の利点が追加される：

  • アーキテクチャ出力の包括的なチェックリストを提供する。
  • 企業全体で採用された場合、作業成果物の統合をより良好に促進する。
  • アーキテクチャがどのように記述されるべきかについての詳細なオープン標準を提供する。

成果物、アーティファクト、ビルディングブロック

成果物は、作成が義務付けられ、ステークホルダーによって正式にレビューされ、承認され、署名される作業成果物を指す。プロジェクトの出力は通常、成果物カテゴリに属し、文書形式で作成され、プロジェクト完了時にアーカイブされるか、アーキテクチャリポジトリに移動され、アーキテクチャランドスケープの参照モデル、標準、またはスナップショットとして利用される。

アーキテクチャコンテンツフレームワークは、ADMプロセス中に開発される出力の種類を分類するために3つの異なるカテゴリを使用する。TOGAFアーキテクチャコンテンツフレームワークの3つのカテゴリは以下の通りである：

  • 成果物
  • アーティファクト
  • ビルディングブロック

アーティファクト

アーティファクトは、アーキテクチャの側面を記述する作業成果物を指す。アーティファクトは以下の通り分類される：

  • カタログ – 物のリストを表示するために使用
  • マトリクス – 物同士の関係を表示するために使用
  • 図 – 物の図

ビルディングブロック

ビルディングブロックは、組織全体のビジネスニーズを満たすために定義された機能のパッケージである。ビルディングブロックはしばしば異なるレベルで使用される。初期分析段階では、顧客関係管理（CRM）などの概念的なビジネス能力を表現するために使用できる。また、概念的な能力を、顧客マスターデータなどの機能に細分化し、さらに詳細にマネージャーの任命、顧客連絡の管理などにまで具体化することも可能である。

 

第5部：エンタープライズコンティニュム＆ツール

仮想リポジトリを構造化するためのモデルおよびアーキテクチャとソリューションアーティファクトを分類する方法。TOGAF 9では以下の変更が加えられている：

  • 大幅に改訂
  • 参照モデルは第6部に移動された
  • アーキテクチャのパーティショニングおよびアーキテクチャリポジトリに関する新しいコンテンツが追加されました
  • 標準情報ベース（SIB）が削除されました

エンタープライズコンティニューム対ソリューションコンティニューム

図の上部では、アーキテクチャ（アーキテクチャコンティニューム）の論理的側面が説明されており、下部ではアーキテクチャの物理的実現（ソリューションコンティニューム）が述べられています

汎用的アーキテクチャ対特定的アーキテクチャ

また、図は左側の「より汎用的な」アーキテクチャから右側の「より特定的な」アーキテクチャへと構成されており、問題の初期段階から最終的なソリューションに至る過程で、アーキテクチャを「論理的」から「物理的」へ、また「より汎用的」から「より特定的」へと段階的に精緻化できるようにしています

パーティショニング

アーキテクチャのパーティショニングは、エンタープライズを分割し、各パーティションに適切な役割と責任を割り当てることで、コストと複雑さの管理を可能にします。この図は、異なるビジネスユニットの個々のアーキテクトに対して統合フレームワークを提供するメタアーキテクチャの必要性を示しています

 

アーキテクチャリポジトリ

アーキテクチャリポジトリは、参考資料やアーキテクチャ作業の成果物を整理するための論理的な場所です。その一部または全部は、VPの文書キャビネットなどの物理的リポジトリツールにアーカイブされる可能性があります。また、何が格納されるかを定義する概念モデルでもあります。アーキテクチャリポジトリの主要な構成要素は以下の通りです：

 

  • そのアーキテクチャメタモデル組織に合わせてカスタマイズされたアーキテクチャフレームワークの適用を記述しており、アーキテクチャコンテンツ用のメタモデルを含んでいます
  • そのアーキテクチャ能力アーキテクチャリポジトリのガバナンスを支援するためのパラメータ、構造、プロセスを定義します
  • そのアーキテクチャランドスケープ現在組織内で使用されている構成要素（例：稼働中のアプリケーションの一覧）のアーキテクチャ的視点を示します。このランドスケープは、異なるアーキテクチャ目的に応じて、複数の抽象度レベルで存在する可能性があります
  • その標準情報ベース（SIB）は、新しいアーキテクチャが遵守しなければならない基準を収集しており、業界標準、サプライヤーからの選定された製品やサービス、または組織内で既に展開済みの共有サービスを含むことがあります
  • そのリファレンスライブラリガイドライン、テンプレート、パターン、その他の参考資料を提供し、企業向け新しいアーキテクチャの作成を加速するために活用できます
  • そのガバナンスログ企業全体におけるガバナンス活動の記録を提供します

第VI部：参照モデル

TOGAF 9では、参照モデルの定義が大幅に改訂されました。提供される参照モデルは以下の2つです：

  1. 技術的参照モデル（TRM）－汎用プラットフォームサービスのモデルおよび分類体系として機能する基盤アーキテクチャ。
  2. 統合情報インフラストラクチャモデル（III-RM）－ビジネスアプリケーションおよびインフラストラクチャアプリケーションのためのモデル

参照モデルをアーキテクチャ連続体に関連付ける

アーキテクチャ連続体は4つの状態で構成される。その基盤となるプロセスは、組織内で既に存在するアーキテクチャを発見し、分析し、理解することである。これには、基盤アーキテクチャ（例：TRM）、共通システムアーキテクチャ（III-RM）、業界標準アーキテクチャ（例：SOA）、そして組織独自のアーキテクチャを含む。以下の図は、4つの状態に基づくアーキテクチャプロセスの例である。

  • 基盤アーキテクチャ（TRM）
  • 共通システムアーキテクチャ（III-RM）
  • 業界アーキテクチャ
  • 組織アーキテクチャ

左側の状態に加えられたアーキテクチャ変更は、右側の状態へと移行する。左から右への方向性は、企業アーキテクチャの実装を整理する上で論理的な進展を示している。

第7部：アーキテクチャ能力フレームワーク

この部では、企業内にアーキテクチャ活動を確立し運用するために必要な組織、プロセス、スキル、役割、責任について説明する。TOGAF 9における新規の部であり、8.1.1リソースベースに基づいて構築されている。

アーキテクチャ能力の構造

企業アーキテクチャの開発は、異なる開発フェーズを通じて、組織のすべてのレベルでビジネス能力の構築、アーキテクチャの計画および管理を含む。企業は、図の上部に示すように、アーキテクチャ意思決定を行う責任を負うガバナンス機関を特定する必要がある。

右側の中央部では、TOGAFは組織の成熟度とその改善を記録するアーキテクチャスキルプールを規定している。したがって、アーキテクチャ専門家のスキル、知識、および専門的発展戦略を含む。これらの知識により、アーキテクチャ作業における役割と責任を定義できる。言い換えれば、「誰が何を責任を持つのか？」を明確にする。

スキルプールの右側では、プロジェクト／ポートフォリオガバナンスがアーキテクチャ作業の契約をプロジェクト／ポートフォリオに送付する。これは、ビジネス運用の優先順位と焦点と整合している必要がある。

成果物、アーティファクト、ログ、またはポリシーペーパーは、企業連続体およびアーキテクチャリポジトリから抽出できる。

一般的な考え方は、組織のアーキテクチャ開発能力を進化させることであり、その結果としてビジネス能力が向上することである。

アーキテクチャボード－ボードはガバナンス戦略の実施を監視する。この戦略は、アーキテクチャのレビューおよび維持を担当する代表的ステークホルダーから構成される。

アーキテクチャ準拠－アーキテクチャと実装の間の重要な関係は、個々のプロジェクトが企業アーキテクチャに準拠していることを保証するための「準拠」の定義にある。

アーキテクチャ契約－開発パートナーとスポンサー間の合意事項として、成果物、品質、および目的適合性に関するもの

アーキテクチャ成熟度モデル－企業が現在の位置を評価する手段として用いられ、したがって、前進する適切な時期とその方法をよりよく理解するためのものである。

アーキテクチャスキルフレームワーク－特定の役割に求められる能力レベルを示すものである。

参考文献：

コメントを残す