かつて運営していて、今は放置しているブログにTOGAF関連の情報を求めてのアクセスがあることに気づきました。中途半端ではあるのですが、TOGAF関連の情報は次のwikiにまとめています。
seesaawiki.jp
このエントリーは、その放置しているブログから引き継いだものです。情報は2008年のもので、TOGAF 8の内容に基づいています。wikiはTOGAF 9のものです。wikiと併せてご参照ください。
Phase B: Business Architecture
まず最初に策定するのがビジネス・アーキテクチャ。それはどういうものかというと、具体的には、下記事項をまとめたもの。
・ビジネス環境、プロセス、構成人員とそれらの相互関係をまとめます。
・ビジネス・デザインとその展開をコントロールするための原則
こんなことをまとめて、それをステークホルダーと確認し、組織とそのビジネス、彼らのゴールがフィットしているかを確認するわけですね。
とは言え、それらがフィットしていることはまずないわけで、現状をBA (Baseline Architecture)としてまとめると同時に、それがフィットした理想的な状態、すなわちTA (Target Architecture)を定義するわけです。これがこのフェーズの成果物にして目的。
アーキテクチャ策定の流れは大筋で把握しているので、
それを元に、Business Architectureならではの要素を確認していきます。
[INPUTS]
・Request for Architecture Work
・Approved Statement of Architecture Work
・Refined statements of business goals and strategic drivers
・Business Strategy, business goals, business drivers
・Architecture Principles, including Business Principles
・Enterprise Continuum（既存のアーキテクチャ文書）
・Architecture Vision
Architecture Visionには各ドメインのArchitecture Version 0.1が含まれていることに注意。
1. develop Baseline Business Architecture
Bottom-upで現状分析を行います。Bottom-upというのはつまり現場。実際に現場はどうなっているのか？と調べまくります。ここで注意するのがBuilding Blocks (BB)。
BBとはビジネス機能を概念上のまとまり、パッケージとして定義したもので、イメージとしてそのまとまりがブロックや積み木のように認識される感じ？このまとまりを定義すると、大きなビジネス構造も積み木やブロックを組み立てるように定義できるわけですね。
ビジネス機能はFunctionalityと呼ばれますが、このFunctionalityがパッケージされたものを、Architecture Building Blocks (ABB)、と呼びます。
そのFunctionalityが組み合わされて再利用可能な一つのソリューションにまとめられたものを、もしくは必要な機能を含む製品(Products)を、特にSolution Building Blocks (SBB)と呼びます。
2. identify Reference Models, Viewpoints, and Tools
アーキテクチャ策定にあたり、それに関連しそう、再利用できそうなモデルや必要なツールなどを識別するわけですが、注意しなければならないのがViewpoints。これの識別というのは、つまり策定しようとしているアーキテクチャのステークホルダーの識別に包含されています。
アーキテクチャにはステークホルダーの関心事項が反映される必要があるわけですが、誰がどんな事を考えているのか、ということを事前に特定しておく必要があるわけですね。システムに対するステークホルダーの関心事項や観点をViewpoints、異なるステークホルダー間のViewpointsを総合することで得られる、システムの全体像をViewと呼びます。
3. create Architecture Models
ここからアーキテクチャをモデリングしていきます。モデリングは次の観点から行います。
- Organization structure
- Business goals and objectives
- Business functions
- Business services
- Business processes
- Business roles
- Correlation of oeganization and functions
これらビジネス要件をまとめるにあたっては、Business Scenariosを活用します。
また、必ずしも全ステークホルダーのViewpointsをアーキテクチャに反映されるとは限らず、どの関心事項をアーキテクチャに盛り込むのかを判断するにあたって、トレード・オフを考慮する必要があります。
ちなみに、代表的な分析法はArchitecture Trade-off Analisys Method (ATAM)。
4. select Business ABB
どこにどんなBBが必要かを考え、既存のBBを再利用、新しく必要なBBを検討します。
5. conduct a Formal Checkpoint review of the Architecture Model and BB with stakeholders
Checkpoint reviewはアーキテクチャ策定において、かなり重要なポイント。このレビューを通過できない場合には、必要なステップに逆戻りして必要な作業を行います。
ここでは、4までに作成したアーキテクチャとStatement of Architecture Workに定義されたBusiness Architectureを比較し、その整合性を確認します。
レビューは必ずステークホルダーとともに行いますよ。
6. review Non-Functional (Qualitative) criteria
定性的な要素についての評価基準（必要なサービス・レベルとか）を検討します。
ここらでそろそろ字数制限に達しそうなので、次のエントリへ続く。
