Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

Phase C: Data Architecture - 後編

f:id:espio999:20180320222407j:plain
かつて運営していて、今は放置しているブログにTOGAF関連の情報を求めてのアクセスがあることに気づきました。中途半端ではあるのですが、TOGAF関連の情報は次のwikiにまとめています。
seesaawiki.jp

このエントリーは、その放置しているブログから引き継いだものです。情報は2008年のもので、TOGAF 8の内容に基づいています。wikiはTOGAF 9のものです。wikiと併せてご参照ください。

Phase C: Information Systems Architectures - Data Architecture
昨日に引き続いてData Architecture。今回は、そのOutputsの紹介です。

まず、Outputsの一覧から。

[Outputs]
・Statement of Architecture Work(更新が発生した場合)
・Baseline Data Architecture 1.0
・Validated data principles, or new data principles(更新が発生した場合)
・Target Data Architecture 1.0
ステークホルダーの関心事項が特定されたViewpoints
・Viewpointsに対応するView
・ギャップ分析結果
アーキテクチャ開発サイクルに関連する技術要件
・影響分析(Impact Analysis)の結果
・更新されたビジネス要件

どれも見慣れたものばかりですが、数点注意。まず、Target Data Architecture。この成果物には次の要素が含まれている必要があります。

・Business data model
・Logical data model
・Data management process models
・Data entity/business function matrix
・Data interoperability requirements

要は、

どのようなデータが必要で、それらはどのように構成(スキーマ)されるのか?
データはどのように生成され、運用されるのか?
データ要素とビジネス機能との関連性、どの機能がどのデータを必要とするのか?
データの相互作用、関連性

をまとめなさいということ。実はこれって、先日のStepsで散々検討とレビューを重ねたものだったりします。
そして、ViewpointsとViews。これらも同様に次の要素を反映している必要があります。

・Data Dissemination view
・Data lifecycle view
・Data security view
・Data model management view

データ分布からそのライフ・サイクル、セキュリティから運用まで、やはり先のStepsでさんざん検討、レビューを重ねたものです。

勘の良い人はお気づきでしょうが、Stepsで検討、レビューを重ねた要素のほとんどは、何らかの形で文書にまとめ、公式な成果物としてリリースする必要があるのですね。
アーキテクチャ活動では生成される成果物、特に文書がものすごく多いです。プロジェクト・マネジャ業務の8割はコミュニケーションに費やされるといいますが、アーキテクトの場合、その業務の8割はミーティング、レビューと文書作成でと言われます。その所以は、こういうところにあるわけですね。

アーキテクチャ開発の各フェーズで何を検討しなければならないのか?を知っていれば、それらの検討を重ね、記録を残しておくことで、業務で求められる成果物は、おのずと出来上がるわけですね。
また、テスト対策としましては、各フェーズ、ステップで検討されるものを把握していれば、わざわざフェーズごとの成果物を暗記しなくても、おおよその見当はつくわけで、無理に暗記勉強する必要はないわけです。