かつて運営していて、今は放置しているブログにTOGAF関連の情報を求めてのアクセスがあることに気づきました。中途半端ではあるのですが、TOGAF関連の情報は次のwikiにまとめています。
seesaawiki.jp
このエントリーは、その放置しているブログから引き継いだものです。情報は2008年のもので、TOGAF 8の内容に基づいています。wikiはTOGAF 9のものです。wikiと併せてご参照ください。
Preliminary Phase: Framework and Principles
アーキテクチャ開発のサイクルに突入する直前の一番最初のフェーズがPreliminary Phase。このフェーズでは、Principlesと呼ばれるアーキテクチャ活動における原理・原則、および、活動に利用するフレームワークを定義します。
アーキテクチャ開発プロジェクトを組織化し、どのようにしてアーキテクチャ活動を実施するか？を特定するのがゴール、ということ。
ちなみに、このPrinciplesとFrameworkをまとめて、
How we do Architecture
と呼びます。
[INPUTS]
このフェーズでは、次のツールを用います。
・ADM
・Other architecture framework
・Business strategy
・IT governance strategy
・Architecture Principles, including Business Principles
・Other federated architecture principles
これからprinciplesを作ろうかというのに、何故architecture principlesがINPUTSなのかというと、時として要件はprinciplesとして提示されることがあるから。
そもそも、Principleとは従うべき行動指針やガイドラインです。こと、Business Principlesに関しては、時として極めてhi-levelな要件を示しうるのですね。たとえば、
・システムはいつでも、どこでも利用可能に！
・絶対にBusiness Continuityを犠牲にしてはならん！
とかね。
TOGAFではPrincipleを次の3レベルで定義します。
１．Enterprise
組織の意志決定方法、組織がどのようにアーキテクチャ活動に取り組むのかに関する指針。
２．IT
IT資産、リソースの展開、活用のための指針。
３．Architecture
アーキテクチャ活動、その実装の指針。この2つの指針はそれぞれ、
‐Principles that govern the architecture process
‐Principles that govern the implementation of architecture
と表現されます。
そんなPrincipleの各項目を定義するにおいて、テンプレートとして次の要素に着目せよと言われています。
・name
Principleの項目。覚えやすく、ルールを端的に表現する。「サポートする」「運用する」「考慮する」みたいに曖昧な表現は絶対使っちゃダメ。
・Statement
項目の内容。name同様、曖昧な表現は絶対に使っちゃダメ。
・Rationale
項目に関する論理的根拠を提示する。Principleに則るメリットを、一般的なビジネス用語を用いて強調すること。
・Implications
ビジネスとITの関係性、要件をリソース、コスト、活動の観点から明らかにしておくこと。
[OBJECTIVES]
INPUTSを活用、参照しながら、次の作業を実施します。
・ステークホルダーから、アーキテクチャ活動の確約を取る。
・Principlesの定義。
・関係者の担当、責任を明確にする。
architecture footprintと呼ばれます。
・アーキテクチャ活動における前提条件とスコープの特定。
・フレームワークが目的に合致しているか確認する。
[OUTPUTS]
このフェーズを通じて、次の成果物を出力します。
・Architecture Principles
・Framework definition
・Restatement of business principles, goals and drivers
