かつて運営していて、今は放置しているブログにTOGAF関連の情報を求めてのアクセスがあることに気づきました。中途半端ではあるのですが、TOGAF関連の情報は次のwikiにまとめています。
seesaawiki.jp
このエントリーは、その放置しているブログから引き継いだものです。情報は2008年のもので、TOGAF 8の内容に基づいています。wikiはTOGAF 9のものです。wikiと併せてご参照ください。
Phase A: Architecture Vision
アーキテクチャ開発における最初のフェーズがArchitecture Vision。アーキテクチャ活動をプロジェクトと捉えるならば、その開始を明確にするとともに、その内容をきちんと定義することが、このフェーズのゴールになります。
プロジェクトということは、当然のことながら、
・ステークホルダー
・スコープ
・プロジェクトが他に及ぼす影響
などなどを判別すると同時に、その活動内容を文書にまとめ、活動の承認をもらうことになります。
活動をまとめた文書がStatement of Architecture Work、そしてその活動においてどのようなソリューションを導入するのか？がArchitecture Visionとしてまとめられるわけです。
[INPUTS]
・Request for Architecture Work
アーキテクチャ活動が必要だからとはいえ、アーキテクトが任意のタイミングで活動を開始できるわけではありません。活動の開始に当たっては、スポンサーの承認が必要なわけですね。そのスポンサーからの作業依頼がこの文書。
これがあって、初めてアーキテクトは活動を開始できるわけです。
・Business Strategy, business goals, business drivers
・Architecture Principles, including Business Principles
・Enterprise Continuum（既存のアーキテクチャ文書）
[STEPS]
このフェーズでは、次のステップで作業を進めます。
１．プロジェクトの設立
２．ビジネス・ゴールとドライバの特定
３．Architecture Principlesのレビュー
４．スコープ定義
このADMサイクルにおけるアーキテクチャ活動を定義するわけですが、
‐Breadth of coverage
アーキテクチャの対象範囲
‐Level of detail
どのくらい詳細なアーキテクチャを策定するのか？
なんて、当たり前すぎる要素だけでなく、
‐Assets created in previous iterations of the ADM cycle
前サイクルで生成された成果物。
‐Assets available elsewhere in industry
業界特有の資産。たとえば、全銀協手順とかね.
などなど、利用、参照、影響するものの特定もスコープ要素に含まれるので注意。
５．制約事項の特定
６．以下の項目の特定
‐ステークホルダー
‐ステークホルダーの関心事項
‐ビジネス要件
‐Architecture Visionの記載内容
この最後の段階で重要なことが2つ。一つ目はBusiness Scenarios。
これは、ビジネス上の問題点をビジネス要件としてまとめるためのツール、もしくはプロセス。これについては、また後日紹介します。
2つ目がArchitecture Vision。これはBusiness Scenariosから派生する、いわばhi-levelなアーキテクチャ。4ドメイン、それぞれのアーキテクチャが
Version 0.1
として定義されます。
要は、Business Scenarioを通じてステークホルダーと話し合い、これから何をするのか？をStatement of Architecture Workにまとめ、そこに記載された作業の開始について、ステークホルダーの承認を得るわけです。
[OUTPUTS]
結果として、こんな成果物が生成されます。
・Approved Statement of Architecture Work
・Refined statements of business goals and strategic drivers
・Architecture Principles
・Architecture Vision
