システムアーキテクチャ論 システムアーキテクチャの体系
システムアーキテクチャ
何十年も使われるシステムは土台(システムアーキテクチャ)がしっかりしていないとならない。
- システム構築≒建築
システムアーキテクト≒建築士
システムアーキテクトが不足している。
アーキテクトは、経営からインフラ・運用まで、全てのレベルの要求を把握しなければならない。
EA(Enterprise Architecture)
- Zachman Framework
抽象的
- FEAF(Federal Enterprise Architecture Framework)
モデル定義重視
4層のアーキテクチャ
最上位は、Business。＝システムは仕事をするための手段に過ぎない。
| FEAF |
|---|
| Business |
| Data |
| Application |
| Technology |
- FEA RM(FEA Reference Model)
モデル定義重視
5層のアーキテクチャ
Businessの上にPerformance。＝何のための仕事か、はっきりさせる。
| FEA Reference Model | FEAFの対応層 |
|---|---|
| Performance | 対応階層なし |
| Business | Business |
| Service | Application（FEAFと階層が逆転） |
| Data | Data（FEAFと階層が逆転） |
| Technical | Technology |
- TOGAF(The Open Group Architecture Framework)
プロセス重視。
アーキテクチャの構造は、FEAFのものを利用。
- DODAF(Department of Defense Architecture Framework)
成果物重視。
独自表記版と、UML表記版の2種類を定義。どちらを使っても良い。
FEA RMと関係が強い。
ビジネスモデル
- 古典ビジネスモデル（2000年ネットバブル崩壊以前）
インターネットは、業務改善の手段に過ぎない。
- 新世代のビジネスモデル
インターネットが企業のあり方を変える。
自社のコアのみに注力。コアでない部分はアウトソース。
- 調達システムの変遷
| 通信 | データ | 取引先 | |
|---|---|---|---|
| EDI | 専用線 | 固定長フォーマット | 狭い |
| Web EDI | インターネット | 固定長フォーマット | EDIよりは広い |
| Market Place | インターネット | XML | 広い |
感想
- 目的重要。
最新技術を使ったシステムを作るのが目的、というのは本末転倒。
大前提として、経営目的があり、
経営目的を実現するために、業務があり、
業務をこなすためにシステムを構築するはず。
- アーキテクトになりたい？
- 不要なシステムは作りたくない
不要な開発を防ぐためには、経営レベル・業務レベルで意味があるのか否かの検証が必要。
検証するためには、経営レベル・業務レベルの知識が必要。
でも、僕はそれをできるんだろうか？
-
- 業務知識が無い
知識が無いだけなら、勉強すれば良い。
でも、僕は業務に興味があるんだろうか？
興味があったら、既にもっと知識を身につけているはず。ということは、興味が無かった？
-
- 運用しやすいシステムを作りたい
オペレータや管理者になりたいわけではない。
でも、その経験がないせいで、運用しやすいシステムを作れないんだろうか？
いや、そんなことないよな。
それを言ったらユーザでなければ、ユーザの役に立つシステムを作れない、ってことになってしまう。
