TOGAFとは
エンタープライズアーキテクチャ開発のためのフレームワークと手法を学ぶことができます。米国国防省のTechnical Architecture for Information Managementを起源とした民間用のEAフレームワーク策定を目的としてThe Open Groupにより運営されています。TOGAFの核はArchitecture Development Model ( ADM ) というアーキテクチャ構築の方法になります。本サイトはバージョン９．２の用語となります。
TOGAF研修を受けて学習しましたが、あくまでフレームワークなのでエンタープライズ・アーキテクチャを守破離でいう守が学べます。ただ、独学はなかなか難しいと思います。英語のドキュメントを一人で読んでみましたが理解が浅く、研修受けてようやく理解できました。有識者にポイントを習うのが一番早いです。BABOK同様にぜんぜんすっと入ってこない。ADMは反復するのですが、学習も反復しましょう。（笑）
<ADM>
初期フェーズ
アーキテクチャケイパビリティ策定のための準備と開始のアクティビティ
アーキテクチャ策定作業依頼、スポンサの任命、エンタープライズアーキテクチャ組織の設立（スポンサーや経営層にレビューしてもらい同意）、予算要件の評価、組織固有アーキテクチャ・フレームワークの定義、プリンシプルの定義（プリンシプルはめったに変更されるべきものでない）、アーティファクト：プリンシプル・カタログ
フェーズA：アーキテクチャビジョン
意欲的なビジョンを策定して、アーキテクチャ策定作業計画書にまとめて承認を獲得（フェーズAはスポンサー組織からのアーキテクチャ策定作業依頼を受けて開始）、アーキテクチャ開発の初期フェーズ、アーキテクチャビジョンはエレベータピッチのようなもので、提案された能力の利点をステークホルダーに説明に利用、アーキテクチャ策定作業計画書の承認（ビジネス変革リスクと軽減アクティビティの特定(初期リスク、残余リスク)、リソース見積もり）、アーキテクチャ・プロジェクト設立、ステークホルダ、関心事、ビジネス要件の特定、ビジネス変革即応性の評価、スコープの定義、アーキテクチャ・ビジョンの開発、ビジネスシナリオ（ビジネス要件を発見、フェーズBで用いられることもある）、ビジネス・ゴールと戦略的ドライバを特定、ケイパビリティ評価、フェーズＡのビルディングブロックはハイレベル（概念レベル）、プリンシプルのレビュー、コミュニケーション計画、アーティファクト：ステークホルダ・マップマトリクス、バリューチェーン・ダイアグラム、ソリューション・コンセプト・ダイアグラム、ビジネス・モデル・ダイアグラム、ビジネス・ケイパビリティ・マップ、バリュー・ストリーム・マップ
フェーズB：ビジネスアーキテクチャ
ビジネスアーキテクチャとはビジネス戦略を実現する方法でフェーズBで詳細が決まる。ターゲットビジネスアーキテクチャを開発して、アーキテクチャ・ロードマップ・コンポーネントの候補を特定する。他のドメインの必須のインプット。ビジネス・ケイパビリティ詳細評価、ビジネス戦略の詳細定義、アーティファクト：P３６７
フェーズC：情報システムアーキテクチャ
ターゲットデータアーキテクチャ、ターゲットアプリケーションアーキテクチャを開発して、アーキテクチャ・ロードマップ・コンポーネントの候補を特定する。アーティファクト：P３６７
フェーズC「アプリケーションアーキテクチャ」で使用する可能性として、 統合情報基盤リファレンスモデル（III-RM）がある。
フェーズD：テクノロジアーキテクチャ
ターゲット情報テクノロジアーキテクチャを開発して、アーキテクチャ・ロードマップ・コンポーネントの候補を特定する。製品選定プロセスが発生する場合もある。大規模な影響がある時はフェーズEで対応されるべき。論理的なソフトウェアとハードウェアの能力を記述するアーキテクチャ領域はテクノロジー・アーキテクチャ。
アーティファクト：P３６７
フェーズE：機会とソリューション
フェーズB～Dのロードマップ・コンポーネントを統合してアーキテクチャロードマップの初版を作成する。トランジション・アーキテクチャを特定する。フェーズB~Dで検討したABBを統合してABBを確定して、SBBを定義する。実装ファクタ・アセスメント/推論マトリクスは、実装/移行計画に影響を及ぼすファクタを文書化するために、フェーズEの最初のステップで作成される。
各ワークパッケージ（ビジネス価値を見出すのはフェーズF）、アーキテクチャロードマップV0.1、実装/移行計画Ver0.1、フェーズB～Dで作成されたギャップ分析結果をレビュー、ビジネス変革即応性評価、移行戦略（グリーンフィールド型、革新型（スイッチオンスイッチオフ）、進化型（TOGAFはこれ））アーティファクト：プロジェクト・コンテキスト・ダイアグラム（実装されるワークパッケージの範囲）、ベネフィット・ダイアグラム
フェーズF：移行プランニング
各ワークパッケージのビジネス価値を見出し、すべてのワークパッケージ、プロジェクト、BBに優先度を付ける、実装/移行計画の完成Ver1.0、アーキテクチャ定義文書の完成、アーキテクチャ要件仕様の完成、アーキテクチャロードマップの完成、教訓の文書化
フェーズG：実装ガバナンス
ターゲットアーキテクチャと実装プロジェクトの適合を確認
ソリューションや実装主導型のアーキテクチャ変更要求に対し、適切なアーキテクチャ・ガバナンス機能を執行する。ビジネスとITのオペレーションを実装、導入に必要なリソースとスキルを特定する。アーキテクチャ・コンプライアンス（フェーズB～Dで適合度についてアセスメントし、適合度のレビューをフェーズGで実施）、アーキテクチャコントラクト（アーキテクチャ策定組織とビジネスユーザ間）、デリバラブルとしてSBB、リスク監視とガバナンスで最新状態に保たれる。
フェーズH：アーキテクチャ変更管理
アーキテクチャ・ライフサイクルが維持されていることを確認
アーキテクチャ・ガバナンス・フレームワークが実行されていることを確認、エンタープライズのアーキテクチャ・ケイパビリティが現行の要件に合致していることを確認、アーキテクチャ再構築を行うと意思決定した場合に発行されるデリバブル：アーキテクチャ策定作業依頼
アーキテクチャ要件管理
アーティファクト：要件カタログ
メモ
作業生成物はアーティファクトと呼ばれ、アーキテクチャリポジトリに格納します。（コンテンツメタモデルで生成物は構造が定義されています）また、リポジトリはエンタープライズコンティニュームというビューを通して分類することができます。例外はあるが、要件管理自体は、要件の処理、対処、優先度の付与はしないことが原則。
アーキテクチャ定義文書：ソリューションの定性的ビュー
アーキテクチャ要件仕様：ソリューションの量的ビュー（実装を測定するためのソリューションの定量的ビュー）
ＡＢＢ：基本的な機能と属性、アーキテクチャ要件を補足、SBBの開発を方向づけガイド
ＳＢＢ：具体的な機能と属性、開発か購入
TRMはSIB（スタンダードインフォメーションベース）開発のための分類体系としても使用できる
コンテンツ・メタモデルはアーキテクチャの中に存在するすべてのタイプの作業生成物の定義を提供し、作業生成物がどのように記述され互いに関連づけられているか示す
コア・メタモデルはアーティファクト間のトレーサビリティを支えるアーキテクチャコンテンツの最小セット
アーキテクチャ委員会設立コストは1回限りのソリューションの防止および自由な開発の防止から生じる節約によりそれ以上の金額が相殺できる
要件影響度アセスメントは現在のアーキテクチャ要件およびアーキテクチャに必要な変更を文書化されたもの。
組織のアーキテクチャリポジトリの構造を定義するアーキテクチャドメインはデータ・アーキテクチャ
TOGAFのガイドラインは、ADMプロセスや専門家をどのように適応させるかを文書化したもの
顧客重視、付加価値、持続可能性を実現するために推奨されるのは？ ＡＤＭ
アーキテクチャー・ケイパビリティはアーキテクチャリポジトリのガバナンスをサポートするパラメータ、構造、およびプロセスを定義する
アーキテクチャー・ケイパビリティ・フレームワーク：アーキテクチャ活動を成功に導くように運用するために、アーキテクチャ・ケイパビリティを実現する組織構造、プロセス、役割、責任、スキルを適切に配置する
アーキテクチャガバナンスとは、エンタープライズアーキテクチャやその他のアーキテクチャを企業全体のレベルで管理・統制されていること
TOGAF規格によると、アーキテクチャガバナンスのアーティファクトは アーキテクチャリポジトリに保存されるべき
＜TOGAF団体＞
http://www.re-gis.com/index-j.html
<EA参考>