IM
Mail
2008/10/13 17：06
Phase C: Applications Architecture - 後編 TOGAF
Phase C: Information Systems Architectures - Applications Architecture
Application ArchitectureのOutputもData ArchitectureのOutputと同じく、Stepsで検討とレビューを重ねたものをまとめた成果物です。
Data Architectureの成果物と合わせて気づくのが、Information Systems ArchitecturesではmodelとViewを重要視していること。結局のところ、繰り返される検討やレビューの話題の中心はこの2点であり、さらには、アーキテクチャ策定の大筋でいうところの、
2. identify, review, validateがInformation Systems Architecturesの肝であるということでしょう。
- reference models
- viewpoints
- tools
- principles
3. create Architecture Models
2008/10/7 22：46
Phase C: Applications Architecture - 前編 TOGAF
Phase C: Information Systems Architectures - Applications Architecture
Information Systems Architecturesのもう一つの構成要素がApplication Architecture。ここでは、
・企業活動に必要なアプリケーション
・必要なデータを生成するのに必要なアプリケーション
を特定します。
Information Systems Architecturesで述べたごとく、並行稼働する場合があるとはいえ、データとアプリケーション、どちらが先なのか迷うところですが、「必要なデータを生成するのに必要な」と書けば、おのずと「データが先」という結論に達しますね。Information Systems Architecturesでも述べた、Data-Drivenというやつです。
あと、Data Architecture同様、紛らしいですが、決してアプリケーションの仕様や、その設計を検討するわけではないので注意です。
ちなみに、TOGAFにおけるアプリケーションの定義とは、
logigal groups of capabilities that manage data and support business functions
ビジネス機能をサポートし、データを運用管理する能力の論理的集合
です。考え方によっては、ビジネスを遂行するためにどのような能力が必要なのか？を特定し、その能力はアプリケーションとしてどのように置き換えられるのか？を定義するのが目的と言えるでしょう。
2008/10/6 22：25
Phase C: Data Architecture - 前編 TOGAF
Phase C: Information Systems Architectures - Data Architecture
Information Systems Architecturesの構成要素の一つがData Architecture。ここでやることは、「企業活動に関連するデータ要素」を定義すること。それは以下のような要素です、
・データの形態
・データの運用、保全、管理
・データの情報源
データベース・デザインやデータ・モデリング、もしくはストレージ構成を検討、定義するわけではないことに注意です。
2008/10/6 21：25
Phase C: Data Architecture - 後編 TOGAF
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)の結果
・更新されたビジネス要件
2008/7/21 22：54
Phase C: Information Systems Architectures TOGAF
Phase C: Information Systems Architectures
Information SystemsというといかにもITな感じですが、実はそれほどでもありません。
そもそもArchitectureというのは非常に抽象的な世界のお話で、Systemsとは言え、ITシステムの具体的な設計、実装案、詳細設計を行うのではありません。っていうか、それは絶対やっちゃダメ。
Information Systems Architecturesでは、データ、アプリケーション・ドメインにおけるアーキテクチャ策定を行います。
具体的には、Business Architecturesでまとめたアーキテクチャを実現するためには、どんなITシステム（データ、アプリケーション）を構成するのか、をアーキテクチャとしてまとめるわけです。
どういう実装のシステムにしようか？をアーキテクチャとしてまとめるのは、この次のTechnology Architectures。
このフェーズでは、異なる2ドメインのアーキテクチャを策定する都合、1フェーズ内で2回のアーキテクチャ活動を行うことになります。それぞれの活動をの説明は次回以降として、今回は個別説明に移る前の概要説明です。
2008/7/21 3：00
Phase B: Business Architecture - 後編 TOGAF
Phase B: Business Architecture
前エントリから続く。
7. Complete the Business Architecture
アーキテクチャ策定作業を終了するにあたって、諸々の検討事項とその結果を文書にまとめる必要があります。具体的には、
・各ABBの文書化
・最終ビジネス要件
・ABBのマッピング
・BB選択決定の論理的根拠
・活動履歴報告
・Business Architecture文書
アーキテクチャ活動には、何かにつけミーティングやレビュー、文書作成が伴います。プロジェクト・マネージャの活動の8割ほどはコミュニケーションに費やされると言われますが、アーキテクチャも似たような感じです。
2008/7/21 1：40
Phase B: Business Architecture - 前編 TOGAF
Phase B: Business Architecture
まず最初に策定するのがビジネス・アーキテクチャ。それはどういうものかというと、具体的には、下記事項をまとめたもの。
・ビジネス環境、プロセス、構成人員とそれらの相互関係をまとめます。
・ビジネス・デザインとその展開をコントロールするための原則
こんなことをまとめて、それをステークホルダーと確認し、組織とそのビジネス、彼らのゴールがフィットしているかを確認するわけですね。
とは言え、それらがフィットしていることはまずないわけで、現状をBA (Baseline Architecture)としてまとめると同時に、それがフィットした理想的な状態、すなわちTA (Target Architecture)を定義するわけです。これがこのフェーズの成果物にして目的。
アーキテクチャ策定の流れは大筋で把握しているので、
アーキテクチャ策定の解説を始める前に
それを元に、Business Architectureならではの要素を確認していきます。
2008/7/13 23：54
アーキテクチャ策定の解説を始める前に TOGAF
これから続く3フェーズは、
Phase B: Business Architecture
Phase C: Information Systems Architectures
- Data Architecture
- Applications Architecture
Phase D: Technology Architectures
と、本格的なアーキテクチャ策定のフェーズに突入するのですが、ちょっとその前に。先に知っておくと後の理解がたやすくなる仕掛けと言いますか、ちょっとした入れ知恵を紹介します。
2008/6/30 23：27
Business Scenarios TOGAF
Business Scenarios
Business Scenariosは、次の要素を識別、特定し、文書化するためのツール、もしくはプロセス。
‐Problem
問題点とその重みづけ
‐Business and Technical Environments
どこで問題が発生しているのか、何が問題なのかも特定する。
‐Objectives and Measures of Success
何がどうなったら成功なのか？をきちんと定義する必要がありますね。
‐Human Actors
分析対象に関連する人的要素。
‐Computer Actors
分析対象に関連するIT要素。
‐Roles and Responsibilities
Actorごとの役割や責任をまとめるだけでなく、それぞれの成功要素、指標を定義する必要もあります。
2008/6/30 2：10
Phase A: Architecture Vision TOGAF
Phase A: Architecture Vision
アーキテクチャ開発における最初のフェーズがArchitecture Vision。アーキテクチャ活動をプロジェクトと捉えるならば、その開始を明確にするとともに、その内容をきちんと定義することが、このフェーズのゴールになります。
プロジェクトということは、当然のことながら、
・ステークホルダー
・スコープ
・プロジェクトが他に及ぼす影響
などなどを判別すると同時に、その活動内容を文書にまとめ、活動の承認をもらうことになります。
活動をまとめた文書がStatement of Architecture Work、そしてその活動においてどのようなソリューションを導入するのか？がArchitecture Visionとしてまとめられるわけです。
