こんばんは。torippy1024です。
TOGAF認定試験の勉強中です。今回はTOGAFのメイントピックであるADM(アーキテクチャ開発手法)についてまとめます。
試験の7-8割もAMDに関する問題らしいので、しっかり勉強していきます。
(Level2は総合問題っぽいので、それはLvel1に関する割合のような気もしますが)
AMD(アーキテクチャ開発手法)について
AMDは、TOGAFの中核となるフレームワークです。
AMDは、初期フェーズ、フェーズA〜Hまでの合計9フェーズと、アーキテクチャ要件管理という全体を管理するプロセスから構成されます。
画像引用元：https://pubs.opengroup.org/togaf-standard/adm/chap01.html
フェーズA〜Hは、反復して実行されることを想定されているのが特徴です。
AMDの各フェーズの概要と主な入力/出力
順にそれぞれのフェーズの概要と、主な入力と出力を記載します。
入力と出力については、TOGAFのガイドに記載されている量を全て書くと膨大になるため、独断と偏見で重要そうに思ったものだけを書いておくことにします。
初期フェーズ(Preliminary Phase)
概要
初期フェーズでは、ADMサイクルを実行するための前提事項を整理します。
エンタープライズの戦略や組織モデルから、アーキテクチャを作成するための土台(ビジネス・プリンシプルの定義、使用するフレームワークの決定、エンタープライズ・アーキテクチャ成熟度の評価など)を決定します。
主な入力
- 経営戦略、ビジネス戦略、IT戦略など
- 組織モデル(組織のスコープ、アーキテクチャチームの役割、予算、ガバナンスなど)
- アーキテクチャ・フレームワーク(TOGAF以外の他のフレームワークを利用することも含む)
- アーキテクチャ・ケイパビリティ
主な出力
- 再確認されたビジネス・プリンシプル、ビジネル・ゴール、ビジネス・ドライバ
- 組織に適用されると判断された・調整されたアーキテクチャ・フレームワーク
- アーキテクチャ策定作業依頼
重要な成果物として「アーキテクチャ策定作業依頼」があります。
(ガイドではなぜかオプションになっていますが、これは経営層がアーキテクチャチームに作業を依頼したエビデンスとなるため、基本的にはあったほうがよいと思われます)
フェーズA：アーキテクチャ・ビジョン(Architecture Vision)
概要
フェーズAでは、今後フェーズA〜Hまでの1サイクルによって策定し、実装するアーキテクチャを明確にします。
ビジネスのプリンシプル、ゴール、ドライバを入力として、アーキテクチャ・ビジョンを決定します。
ビジネス変革相応性を評価することによってアーキテクチャ策定計画を立てたりリスク評価を行います。
アーキテクチャ策定作業計画書を作成し、経営層に承認してもらいます。
主な入力
- ビジネス・プリンシプル、ビジネス・ゴール、ビジネス・ドライバ
- アーキテクチャ策定作業依頼
- アーキテクチャ・フレームワーク
主な出力
- アーキテクチャ・ビジョン
- アーキテクチャ定義文書のドラフト(ベースライン・アーキテクチャやターゲット・アーキテクチャのドラフトを含む)
- ケイパビリティ・アセスメント(ビジネス変革相応性による出力)
- 承認されたアーキテクチャ策定作業計画書
重要な成果物は「承認されたアーキテクチャ策定作業計画書」です。
フェーズB：ビジネス・アーキテクチャ(Business Architecture)
概要
フェーズBでは、アーキテクチャ・ビジョンをもとに、ビジネス・アーキテクチャを作成します。
ベースライン・ビジネス・アーキテクチャと、ターゲット・ビジネス・アーキテクチャを作成し、ギャップ分析を行なってビジネス・アーキテクチャ・ロードマップ・コンポーネントの候補を抽出します。
(フェーズBで抽出するのはあくまでアーキテクチャ・ロードマップ・コンポーネントの「候補」であり、これらはフェーズEにて確定される)
主な入力
- ビジネス・プリンシプル、ビジネス・ゴール、ビジネス・ドライバ
- アーキテクチャ・ビジョン
- アーキテクチャ定義文書のドラフト(ベースライン・アーキテクチャやターゲット・アーキテクチャのドラフトを含む)
主な出力
- アーキテクチャ定義文書(ベースライン・ビジネス・アーキテクチャやターゲット・ビジネス・アーキテクチャ)
- ビジネス・アーキテクチャ・ロードマップ・コンポーネントの候補
フェーズC：情報システムアーキテクチャ(Information System Architecture)
概要
情報システムアーキテクチャとは、データ・アーキテクチャとアプリケーション・アーキテクチャの二つのことを指しています。フェーズCでは、データ・アーキテクチャとアプリケーション・アーキテクチャの二つを作成することが目的です。
ベースライン・データ/アプリケーション・アーキテクチャと、ターゲット・データ/アプリケーション・アーキテクチャを作成し、ギャップ分析を行なってデータ/アプリケーション・アーキテクチャ・ロードマップ・コンポーネントの候補を抽出します。(うーん、書いていて意味がわからくなってきた。。。)
作業内容はほとんどフェーズB：ビジネス・アーキテクチャと変更はありません。
また、データとアーキテクチャを先に作成する場合と、アプリケーション・アーキテクチャを先に作成する場合の２パターンがあるようです。
主な入力
- ビジネス・プリンシプル、ビジネス・ゴール、ビジネス・ドライバ
- アーキテクチャ・ビジョン
- アーキテクチャ定義文書のドラフト(ベースライン・アーキテクチャやターゲット・アーキテクチャのドラフトを含む)
主な出力
- アーキテクチャ定義文書(ベースライン・データ・アーキテクチャ、ベースライン・アプリケーション・アーキテクチャ、ターゲット・データ・アーキテクチャ、ターゲット・アプリケーション・アーキテクチャ)
- データ・アーキテクチャ・ロードマップ・コンポーネントの候補
- アプリケーション・アーキテクチャ・ロードマップ・コンポーネントの候補
フェーズD：テクノロジ・アーキテクチャ(Technology Architecture)
概要
フェーズC、Cと同じく、フェーズDでは、テクノロジー・アーキテクチャを作成します。
ステップはほぼ同じです。
主な入力
- ビジネス・プリンシプル、ビジネス・ゴール、ビジネス・ドライバ
- アーキテクチャ・ビジョン
- アーキテクチャ定義文書のドラフト(ベースライン・アーキテクチャやターゲット・アーキテクチャのドラフトを含む)
主な出力
- アーキテクチャ定義文書(ベースライン・テクノロジ・アーキテクチャ、ターゲット・テクノロジ・アーキテクチャ)
- テクノロジ・アーキテクチャ・ロードマップ・コンポーネントの候補
フェーズE：機会とソリューション(Opportunity and Solution)
概要
フェーズEでは、フェーズB~Dにて作成したアーキテクチャ・ロードマップ・コンポーネントの候補をもとに、アーキテクチャ・ロードマップ・コンポーネントの完成版を作成します。
またターゲット・アーキテクチャを実装するため、アーキテクチャ・ビルディング・ブロック(ABB)を確定させ、ソリューション・ビルディング・ブロック(SBB)を定義し、トランジション・アーキテクチャの特定します。
主な入力
- アーキテクチャ定義文書(ビジネス/データ/アプリケーション/テクノロジードメインの各ベースライン・アーキテクチャやターゲット・アーキテクチャ)
- ビジネス/データ/アプリケーション/テクノロジードメインの各アーキテクチャ・ロードマップ・コンポーネントの候補(ABBも含む)
主な出力
- アーキテクチャ定義文書(トランジション・アーキテクチャ)
- アーキテクチャ・ロードマップ・コンポーネントの完成版
- ソリューション・ビルディング・ブロック(SBB)
- 実装/移行計画のドラフト
フェーズF：移行プランニング(Migration Planning)
概要
フェーズFでは、アーキテクチャ・ロードマップと実装/移行計画を完成させます。
アーキテクチャ定義文書はここで完成版になります。
実装と移行に向けたコスト/ベネフィットの評価を行い、スケジュールをするのがこのフェーズです。
主な入力
- アーキテクチャ定義文書(これまで作成してきたアーキテクチャ)
- アーキテクチャ・ロードマップ・コンポーネントの完成版
- 実装/移行計画のドラフト
主な出力
- アーキテクチャ定義文書の完成版
- アーキテクチャ・ロードマップの完成版
- 実装/移行計画の完成版
フェーズG：実装ガバナンス(Information Gavarnance)
概要
フェーズGでは、ターゲットアーキテクチャがフェーズFの計画に沿って実装されていることを確認します。
アーキテクチャ・コンプライアンスやアーキテクチャ・コントラクトの管理、リスク監視などを行います。
アーキテクチャに準拠したソリューションがデプロイ(実装しリリース)されたことでフェーズGは完了します。
主な入力
- アーキテクチャ・コントラクト(テンプレート)
- アーキテクチャ・ロードマップ
- 実装/移行計画
主な出力
- アーキテクチャ・コントラクト(署名済み)
- アーキテクチャに準拠したデプロイされたソリューション
- コンプライアンス・アセスメント
フェーズH：アーキテクチャ変更管理(Architecture Change Management)
概要
フェーズHでは、アーキテクチャ・ライフサイクルを次に進めるための判断を行います。
つまり、フェーズGまででデプロイされたソリューションのアーキテクチャがビジネス価値を出しているか、変更要求が出ているかどうかなどを踏まえ、次のアーキテクチャ策定作業依頼を出します。
主な入力
- 変更要求
主な出力
- アーキテクチャ策定作業依頼
アーキテクチャ要件管理(Requirement Management)
概要
アーキテクチャ要件管理は、フェーズA〜Hの全フェーズにおいて、変更されたアーキテクチャ要件を管理します。
ビジネスは普遍的なものであるため、変化を伴い、それにともなってアーキテクチャ要件も変化します。
アーキテクチャ要件管理プロセスは、あくまで出された要件をまとめ、管理することであり、これら要件の処理、対処、優先度の付与などはそれぞれのフェーズで実施します。
主な入力
- アーキテクチャ要件仕様
- 変更されたアーキテクチャ要件
主な出力
- アーキテクチャ要件仕様(更新版)
- 要件影響度アセスメント
(独り言)試験対策としての考察
TOGAFのガイドをしっかり読むと、入力と出力が非常に膨大のため、どこまでやればいいのか悩み始めることになります。
結局、試験対策という視点ではどこまでやればいいか？ということを考えたのですが、万全を期すのであれば、
「それぞれのフェーズの概要を自分の言葉で回答できるようにすること、入力と出力については、前後のフェーズとの関連性を踏まえた上で、重要な入力/出力について覚えておくこと」
くらいまでやっておいたほうがいいな、と思いました。
すると「重要な入力と出力」とは何か、どうやって重要性を判断したらいいかという問題が出てくるのですが、これも、TOGAF Standardの本を読んで、ADMを全体を通して理解する際に重要だと思われる成果物(デリバラブル)を知ったり、研修で講師が教えてくれることを忘れずにメモっておくようにして学べばいいかなと思いました。