【TOGAF9認証試験のための勉強メモ(4)】Tipsその他

こんにちは。torippy1024です。
TOGAF認定試験の勉強中です。本日は、試験対策という意味で重要そうなTips(項目)をかたっぱしから記載していくことにします。まとまってなくてすいません。


## ビジネス・プリンシプルとビジネス・ゴールとビジネス・ドライバ
ビジネス・プリンシプルは、エンタープライズがミッション(使命)を果たすための方向性を示すもの。長期的に変更されないガイドラインである。初期フェーズにてアーキテクチャ・プリンシプルの構成要素として作成される(というか、基本的に大企業にはあるものなので再確認される)。
ビジネス・ゴールは、エンタープライズがビジネスを行う上での目的としているゴールである。
ビジネス・ドライバは、ビジネスを加速させるための要素である。

## デリバラブルとアーティファクト(とビルディングブロック)
アーキテクチャ・コンテンツ・フレームワークでは、生成物を3つに分けている。
デリバラブルとアーティファクトとビルディングブロック。
デリバラブルは契約によって定められた成果物。
アーティファクトはそれよりも広く、中間生成物などを含む。
ビルディングブロックは、アーキテクチャやソリューションを構成するコンポーネント。

## 要件(Requirements)と関心事(Concerns)の違い
要件とは、アーキテクチャが満たすべき要素であり、明示されていることである。SMARTであるべき。これに対し、関心事は、ステークホルダーが関心・興味を持っていることであり、明示されたり数値化されたりしているとは限らない。

## アーキテクチャとソリューション
アーキテクチャは概要的であり、経営層が見てわかるものであることが求められる。アーキテクチャの詳細な仕様がソリューションであり、実装にはこちらが用いられる。

## エンタープライズ・コンティニュームの分類
エンタープライズ・コンティニュームは、アーキテクチャ・コンティニュームと、ソリューション・コンティニュームに分けられる。
そしてアーキテクチャコンティニュームとソリューション・コンティニュームは以下のビューに分けられる。

上に行くほど汎用のコンティニュームであり、下に行くほどエンタープライズに固有のコンティニュームとなる。
上から下のコンティニュームが流れていく場合は、利用のための適用である。
下から上のコンティニュームが流れていく場合は、将来の再利用のための一般化である。

アーキテクチャ・コンティニューム
-ファウンデーション・アーキテクチャ
-共通システム・アーキテクチャ
-業種別・アーキテクチャ
-組織固有・アーキテクチャ

ソリューション・コンティニューム
-ファウンデーション・ソリューション
-共通システム・ソリューション
-業種別・ソリューション
-組織固有・ソリューション

## TOGAF参照モデル
TRM(Technical Reference Model;テクニカル参照モデル)はファウンデーションアーキテクチャ。
III-RM(Integrated Information Infrastructure Reference Model;統合情報インフラストラクチャ・参照モデル)は共通システムアーキテクチャ。

## BDAT
Business, Data, Architecture, Technologyの頭文字をとった用語。アーキテクチャーのドメインを表している。

## ターゲット・アーキテクチャとベースライン・アーキテクチャ
ターゲット・アーキテクチャは、いわゆるToBeのアーキテクチャ。
ベースライン・アーキテクチャは、いわゆるAsIsのアーキテクチャ。
これら2つのアーキテクチャをビルディングブロック単位で比較し、必要なロードマップ・コンポーネントを抽出することをギャップ分析と呼ぶ。これらを実施しているのがフェーズB~Dである。
そしてベースライン・アーキテクチャからターゲット・アーキテクチャに向かうまでの過渡期に位置するアーキテクチャがトランジション・アーキテクチャ。

## ターゲット・ファーストか、ベースライン・ファーストか？
アーキテクチャ策定作業のやり方としては、ターゲット・アーキテクチャを決め、どのようにそれに向かって必要なロードマップ・コンポーネントを洗い出していくか、という方針のアプローチ(ターゲット・ファースト)と、ベースライン・アーキテクチャを決め、それをどのように改善していくか、という方針のアプローチ(ベースライン・ファースト)がある。
TOGAFは経営層向けのフレームワークであるため、ターゲット・ファーストのほうが好まれやすい。ビジネス変革を起こせるのはターゲット・ファーストのアプローチである。

## アーキテクチャ・コンプライアンス
影響度の明確化と、適合度のレビューが重要。
影響度の明確化は、プロジェクト・インパクト・アセスメントにて実施する。フェーズB~Dでランドスケープの影響を調べている。
適合度のレビューは、コンプライアンス・レビューにて実施する。フェーズGで実施している。

## アーキテクチャ定義文書とアーキテクチャ要件仕様
アーキテクチャ定義文書は、ソリューションの定性的な視点で、アーキテクチャの意図を示す。フェーズAでドラフト版(0.1版)を定義し、フェーズFで初期の完成版(1.0版)が確定する。
アーキテクチャ要件仕様は、ソリューションの定量的な視点で、アーキテクチャの測定可能な基準を示す。フェーズEでドラフト版(0.1版)を定義し、フェーズFで初期の完成版(1.0版)が確定する。

## アーキテクチャ適合度
アーキテクチャの仕様と実装がどれほど適合しているかを示す指標。
仕様と実装が完全に一致している場合、「完全適合(Fully Comformant)」と呼ぶ、仕様と異なる実装がある場合「非適合(Non-Comformant)」と呼ぶ。
仕様と実装が一致しているが、一部の仕様が実装されていない(仕様の集合のほうが大きい)場合、「準拠(Compliant)」と呼ぶ。
仕様と実装が一致しているが、一部の仕様に書かれていない機能が実装されている(実装の集合のほうが大きい)場合、「適合(Comformant)」と呼ぶ。
仕様と実装が一致しているが、一部の仕様が実装されておらず、一部の仕様に書かれていない機能が実装されている場合、「整合(Consistent)」と呼ぶ。
同じ機能に関する仕様と実装が存在しない場合、「無関係(Irrelevant)」と呼ぶ。

各用語が紛らわしい、試験対策用の暗記用語。
![comp_levels.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/684500/8f005d29-9698-8ef8-687c-64eb791aff2d.gif)

画像引用元：https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap24.html

## アーキテクチャ委員会
アーキテクチャ・コンプライアンスを執行する組織。
コンプライアンス違反を事例を見つけた場合、(1)要件を満たすために調整や再編成をする、(2)適用免除を要求する、のいずれかを行わなければならない。

## リスク管理におけるリスク・レベル
初期リスク・レベルと残余リスク・レベルがある。
初期リスク・レベルは、発見されたリスクに対して最初に付与するリスク・レベル。影響度と発生頻度を踏まえて決定される。
残余リスク・レベルは、初期リスクに対して軽減活動を行った上で、再評価されたリスク・レベル。
実装フェーズにおけるリスク管理はフェーズGにて実施される。

## コア・メタモデルにおけるサービスと機能の違い
サービスは明確にインターフェースが定義されており、エンタープライズによってガンバンスされており、定量的に評価される。
機能は、サービスほど明確な定義はなく、エンタープライズによるガバナンスがない。